[openstack-dev] [glance] Why no DB index on sort parameters

Nikhil Komawar nikhil.komawar at RACKSPACE.COM
Tue Apr 21 14:39:21 UTC 2015

This is a good idea. We recently removed a unique constraint that may result into some queries being very slow especially those that involve "name" property. I would recommend sketching out a spec that identifies potential full table scans especially for queries that join over image_properties table.

We should discuss there what other use cases look like rather than smaller feedback on the ML.

From: Mike Bayer <mbayer at redhat.com>
Sent: Tuesday, April 21, 2015 9:45 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 4/21/15 2:47 AM, Ajaya Agrawal wrote:
Hi All,

I see that glance supports arbitrary sort parameters and the default is "created_at" while listing images. Is there any reason why we don't have index over these fields? If we have an index over these fields then we would avoid a full table scan to do sorting. IMO at least the created_at field should have an index on it.
just keep in mind that more indexes will place a performance penalty on INSERT statements, particularly at larger volumes.  I have no idea if that is important here but something to keep in mind.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/8ab72781/attachment.html>

More information about the OpenStack-dev mailing list