| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Miroslav Šulc <miroslav(dot)sulc(at)startnet(dot)cz> | 
| Cc: | pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: [PERFORM] How to read query plan | 
| Date: | 2005-03-14 05:00:11 | 
| Message-ID: | 4850.1110776411@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance | 
I wrote:
> Since ExecProject operations within a nest of joins are going to be
> dealing entirely with Vars, I wonder if we couldn't speed matters up
> by having a short-circuit case for a projection that is only Vars.
> Essentially it would be a lot like execJunk.c, except able to cope
> with two input tuples.  Using heap_deformtuple instead of retail
> extraction of fields would eliminate the O(N^2) penalty for wide tuples.
Actually, we already had a pending patch (from Atsushi Ogawa) that
eliminates that particular O(N^2) behavior in another way.  After
applying it, I get about a factor-of-4 reduction in the runtime for
Miroslav's example.
ExecEvalVar and associated routines are still a pretty good fraction of
the runtime, so it might still be worth doing something like the above,
but it'd probably be just a marginal win instead of a big win.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Creager | 2005-03-14 05:09:29 | Re: date_trunc problem in HEAD | 
| Previous Message | Bruno Wolff III | 2005-03-14 04:56:55 | Re: [BUGS] We are not following the spec for HAVING without GROUP | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-03-14 06:29:06 | Re: cpu_tuple_cost | 
| Previous Message | Greg Stark | 2005-03-14 04:36:13 | Re: Postgres on RAID5 |