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. Thanks, -Nikhil ________________________________ 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. Cheers, Ajaya __________________________________________________________________________ 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> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/8ab72781/attachment.html>