[openstack-dev] [glance] Why no DB index on sort parameters
flavio at redhat.com
Tue Apr 21 14:48:22 UTC 2015
On 21/04/15 14:39 +0000, Nikhil Komawar wrote:
>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.
More thatn a spec, I'd be interested in seeing the patch with the
change up and the results reported in Rally.
I guess we'll need a spec anyway, although I'd probably be ok with a
good bug report here.
>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
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev