From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Gyozo Papp" <pgerzson(at)freestart(dot)hu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: about new join syntax performance |
Date: | 2001-05-12 17:15:17 |
Message-ID: | 10050.989687717@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Gyozo Papp" <pgerzson(at)freestart(dot)hu> writes:
> Take a look at this query:
> SELECT * FROM (SELECT did, count(*) FROM values WHERE ... GROUP BY did HAVING count(*) > ...) AS V(did, ok) JOIN document AS D USING(did);
> My question is this significantly faster than two separate queries which are used now (in v7.0.2) via PHP (libpq):
> SELECT did, count(*) INTO TEMPORARY TABLE tmp FROM values WHERE ... GROUP BY did HAVING count(*) > ...;
> SELECT * FROM tmp AS V, document AS D WHER V.did = D.did;
My guess is that you'd get exactly the same component plans, so the
savings would just be the overhead involved in creating, filling, and
eventually deleting a temp table. Hard to tell whether that's
significant or not in the context of this sort of query. (Me, I'd go for
it just so I didn't have to worry about remembering to delete the temp
table before I could issue another similar query.)
You might get a different plan for the join step because it would be
determined by the estimated number of rows output from the subselect,
whereas in the temp-table case you'd just get a default estimate for
the size of the temp table. (I'm assuming you don't stop to VACUUM
ANALYZE the temp table...) Depending on how good the estimate is,
this could be a better or worse plan.
> I'd like to know whether it's worth changing the scripts to use the
> new join syntax.
Try a few and see.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-12 18:05:44 | Re: microsecond log timestamps |
Previous Message | Tom Lane | 2001-05-12 16:55:21 | Re: simple rule question |