| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard) |
| Date: | 2008-12-08 16:56:06 |
| Message-ID: | 27386.1228755366@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
> That might only be the case when the pg_statistic record is in shared
> buffers.
Yeah, it seems unlikely that disabling compression is a good idea in the
bigger scheme of things.
> Also I wonder if eqjoinsel and company might need to be made more
> toast-aware by detoasring all the things it needs once rather than
> every time it accesses them.
At least in this example, the same stats arrays are fetched multiple
times per query. It might be worth teaching the planner to cache those
results internally during a plan cycle --- this would avoid most of the
complexity associated with caching (ie, figuring out when to clear the
cache) and still get maybe a 2x or 3x or so win.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2008-12-08 17:02:14 | Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard) |
| Previous Message | Tom Lane | 2008-12-08 16:26:15 | Re: Optimizing DISTINCT with LIMIT |