yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #84231
[Bug 1901467] [NEW] Listing images which have tens of tags is too slow
Public bug reported:
Our client application retrieves all the images we have. The images have
tens of tags with it. When asking these images with "limit=1000", it
took 10+ seconds in my environment that uses 'mariadb'.
The API query we currently use:
`GET /v2/images?limit=1001&visibility=public`
We have about 200+ public images and half of them have more then 30
tags.
AFAIK, the main reason for this seems to be SQLalchemy and its generated
queries, which use several 'left outer join'; images, image_properties,
image_locations, and image_tags tables are joined. With 'limit=1000',
this produces tremendous numbers of rows to be scanned.
** Affects: glance
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1901467
Title:
Listing images which have tens of tags is too slow
Status in Glance:
New
Bug description:
Our client application retrieves all the images we have. The images
have tens of tags with it. When asking these images with "limit=1000",
it took 10+ seconds in my environment that uses 'mariadb'.
The API query we currently use:
`GET /v2/images?limit=1001&visibility=public`
We have about 200+ public images and half of them have more then 30
tags.
AFAIK, the main reason for this seems to be SQLalchemy and its
generated queries, which use several 'left outer join'; images,
image_properties, image_locations, and image_tags tables are joined.
With 'limit=1000', this produces tremendous numbers of rows to be
scanned.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1901467/+subscriptions
Follow ups