Обсуждение: need some help understanding sloq query
Hi, i have a little performance problem. db (simplified): table current: current_update_id, ... table datasets: set_id, update_id, .... table ents: e_id, set_id, ... table qtys: set_id, e_id, ... indexes are defined on all set_id's & datasets.update_id. an update consists of several sets which in turn consists of several ents, for a specific ent in a set multiple qtys may exist. (normal: 1 update - 1 set - few hundred ents - 1 qty per ent) now i want to do the following: i want to get some specific qty values for the ents of the last update only. so i do a query like: select some_other_fields from ents e, qtys q where e.set_id = q.set_id and e.e_id = q.e_id and e.set_id in (select set_id from datasets where update_id in (select cur_update_id from current)) and q.other_field = some_const ; this query takes ages :( the query plan looks like this: Merge Join (cost=0.00..69979.50 rows=252 width=20) -> Index Scan using qtys_set_id_idx on qtys q (cost=0.00..2054.57 rows=30653width=8) -> Index Scan using ents_set_id_idx on ents e (cost=0.00..66847.20 rows=41196 width=12) SubPlan -> Materialize (cost=1.52..1.52 rows=1 width=4) -> Seq Scan on datasets (cost=0.00..1.52rows=1 width=4) SubPlan -> Seq Scan on current (cost=0.00..1.01rows=1 width=4) after i created an index on the e_id fields the cost went up even higher (about 90.000 for line 1 & 3). this performance isnt acceptable so i started a different approach. instead of joining the larger tables and then checking for interesting set_id's i'd first select the appropriate set_id's (into temp table or view). so i tried something like: select set_id, e_id, some_fields from ents where set_id in (select set_id from datasets where update_id in (select cur_update_id from current)) ; this query is being planned as followed: Seq Scan on ents (cost=0.00..43331.89 rows=41197 width=136) SubPlan -> Materialize (cost=1.02..1.02 rows=1 width=4) -> Seq Scan on datasets (cost=0.00..1.02 rows=1 width=4) InitPlan -> SeqScan on current (cost=0.00..1.01 rows=1 width=4) this query isnt using the created index (!?) and yes, vacuum analyze was done. the 2nd in can be safely changed to = as that is always 1 row. the first in sub-select is returning 1 row about 95% if not 100% of the time, but cant be guaranteed to. if i ignore that and use = for that one as well i get this: Index Scan using ents_set_id_idx on ents (cost=0.00..50.03 rows=37 width=136) InitPlan -> Seq Scan on datasets (cost=0.00..1.02rows=1 width=4) InitPlan -> Seq Scan on current (cost=0.00..1.01 rows=1 width=4) which is more like the performance we want.. using exists instead of in doesnt speed up the 1st query & results in the same plan. so now i'm stumped (and stuck), the 1st approach uses the indices but is way too slow (likely because of the large join?). the 2nd one doesnt use the indices and is (therefore?) way too slow also. clearly i'm doing something stupid here. but what? these tests were done on a db with 30k - 40k rows in the ents & qtys tables but the production db must be able to run with millions of rows and not take minutes (or hours) to cough up a specific set. any help appreciated. Esger Abbink PS. this was on postgres 7.0.3
Esger, > select some_other_fields from ents e, qtys q where e.set_id = > q.set_id and > e.e_id = q.e_id and e.set_id in (select set_id from datasets > where update_id in (select cur_update_id from current)) and > q.other_field = some_const ; > > this query takes ages :( I'm not surprised. You're doing a nested subselect with the IN operator; frankly, you couldn't make a relatively simple query any slower than the above. It looks like the query parser is doing its best to optimize, but you've forced it to compare every row in ents JOIN qtys against the whole datasets table. What's wrong with: SELECT some_fields FROM ents JOIN qtys USING (set_id)JOIN datasets USING (set_id)JOIN current ON datasets.update_id = current.cur_update_id WHERE other_field = some_constant; That allows Tom's magic query engine to do its work optimizing. Assuming, of course, that there *are* indexes on update_id and datasets.set_id ... I heartily recommend that you read Celko's "SQL for Smarties" (book reviews: http://techdocs.postgresql.org/bookreviews.php ). You seem to have fallen into the trap of using complex queries to answer simple questions, and your database performance is suffering because of it. -Josh Berkus
> Esger, > > > select some_other_fields from ents e, qtys q where e.set_id = > > q.set_id and > > e.e_id = q.e_id and e.set_id in (select set_id from datasets > > where update_id in (select cur_update_id from current)) and > > q.other_field = some_const ; > > > > this query takes ages :( > > I'm not surprised. You're doing a nested subselect with the IN > operator; frankly, you couldn't make a relatively simple query any > slower than the above. It looks like the query parser is doing its best > to optimize, but you've forced it to compare every row in ents JOIN qtys > against the whole datasets table. What's wrong with: > > SELECT some_fields > FROM ents JOIN qtys USING (set_id) > JOIN datasets USING (set_id) > JOIN current ON datasets.update_id = current.cur_update_id > WHERE other_field = some_constant; > i figured i wasnt doing things "right" ;) unfortunately the query above takes down my postgres (7.0.3 tried on 2 servers). 1 join no problem, 2 joins results in: DEBUG: Data Base System is in production state at Thu Dec 6 11:42:18 2001 Server process (pid 1095) exited with status 11 at Thu Dec 6 11:45:08 2001 Terminating any active server processes... Server processes were terminated at Thu Dec 6 11:45:08 2001 Reinitializing shared memory and semaphores The Data Base System is starting up this is directly related to executing the query (or just the part with the first 2 joins) and is 100% reproducible sofar. secondly, from the costs explain gives for the query part i can get through (1st join: merge join costs 7800, index scancosts 2000, index scan costs 4200) it seems that doing a simpler variant of my query (see the other post -followup-)with IN replaced by '=' is a lot faster. the resulting query would be something like: select some_other_fields from ents e, qtys q where e.set_id = q.set_id and e.e_id = q.e_id and e.set_id = X and q.other_field = some_const ; this query has negligable costs (nested loop cost 200, index scan cost 50, index scan cost 4 on test db) but should be envelopedin some for-loop construct to feed it the values for X after which the answers should be "glued" together. the setof X's has no theoritical maximum that i can recall atm but in practice it currently is always size 1 and i dont expectmuch if any growth. i cant however assume its size 1. (the above does sound like a complex answer to a simple problem again though..) > That allows Tom's magic query engine to do its work optimizing. > Assuming, of course, that there *are* indexes on update_id and > datasets.set_id ... > > I heartily recommend that you read Celko's "SQL for Smarties" (book > reviews: http://techdocs.postgresql.org/bookreviews.php ). You seem to > have fallen into the trap of using complex queries to answer simple > questions, and your database performance is suffering because of it. will investigate. > > -Josh Berkus > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > -- NeoMail - Webmail that doesn't suck... as much. http://neomail.sourceforge.net
Hello Esger, Esger Abbink schreef: > i have a little performance problem. > > db (simplified): > > table current: > current_update_id, ... > > table datasets: > set_id, update_id, .... > > table ents: > e_id, set_id, ... > > table qtys: > set_id, e_id, ... > > indexes are defined on all set_id's & datasets.update_id. > > an update consists of several sets which in turn consists of several ents, for > a specific ent in a set multiple qtys may exist. > (normal: 1 update - 1 set - few hundred ents - 1 qty per ent) > > now i want to do the following: i want to get some specific qty values for the > ents of the last update only. > > so i do a query like: > > select some_other_fields from ents e, qtys q where e.set_id = q.set_id and > e.e_id = q.e_id and e.set_id in (select set_id from datasets > where update_id in (select cur_update_id from current)) and > q.other_field = some_const ; [SNIP] If I understand correctly, the table current allways contains 1 row, namely the current_update_id, identifying the update that you want to query on. That would mean you could start out from this table and Inner Join all your tables... this way your result-set would be all data for current_update_id: select some_other_fields from ents e, qtys q, datasets s, current c where e.set_id = q.set_id and e.e_id = q.e_id and s.set_id = e.set_id and s.update_id = c.current_update_id and q.other_field = some_const; If you used primary keys and indexes this query should use indexes allways. Other ideas: select some_other_fields from ents e, qtys q where e.set_id = q.set_id and e.e_id = q.e_id and e.set_id in (select set_id from datasets where update_id = (select max(current_update_id)from current)) Given your first example and queryplan, I think the problem is in the Mergejoin; both from qtys and from ents an enormous amount of data is selected that is only narowed down in the last step, the merge-join. I think using my first query, the optimizer will be much more efficient. I couldn't reproduce your query to test though... too much vagueness.... If this doesn't help then post some sql-definitions of your database. Succes, A. Prins.
On Thu, 6 Dec 2001, Esger Abbink wrote: > > Esger, > > > > > select some_other_fields from ents e, qtys q where e.set_id = > > > q.set_id and > > > e.e_id = q.e_id and e.set_id in (select set_id from datasets > > > where update_id in (select cur_update_id from current)) and > > > q.other_field = some_const ; > > > > > > this query takes ages :( > > > > I'm not surprised. You're doing a nested subselect with the IN > > operator; frankly, you couldn't make a relatively simple query any > > slower than the above. It looks like the query parser is doing its best > > to optimize, but you've forced it to compare every row in ents JOIN qtys > > against the whole datasets table. What's wrong with: > > > > SELECT some_fields > > FROM ents JOIN qtys USING (set_id) > > JOIN datasets USING (set_id) > > JOIN current ON datasets.update_id = current.cur_update_id > > WHERE other_field = some_constant; > > > > i figured i wasnt doing things "right" ;) > > unfortunately the query above takes down my postgres (7.0.3 tried on 2 > servers). 1 join no problem, 2 joins results in: If you want to use JOIN, you'll need to upgrade. IIRC, 7.0.x had bugs that caused this kind of failure that were fixed for 7.1. I think the above is equivalent to: select some_fields froments, qtys, datasets, currentwhere ents.set_id=qtys.set_id and ents.set_id=datasets.set_id and datasets.update_id = current.cur_update_id and other_field = some_constant;