| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: hash agg is slower on wide tables? |
| Date: | 2015-02-22 14:58:31 |
| Message-ID: | 15176.1424617111@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> I've wondered before if we shouldn't use the caching via
> slot->tts_values so freely - if you only use a couple values from a wide
> tuple the current implementation really sucks if those few aren't at the
> beginning of the tuple.
Don't see how you expect to get a win that way. Visiting column k
requires crawling over columns 1..k-1 in practically all cases.
You could maybe save a cycle or so by omitting the physical store
into the Datum array, assuming that you never did need the column
value later ... but the extra bookkeeping for more complicated
tracking of which columns had been extracted would eat that savings
handily.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2015-02-22 15:00:28 | Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) |
| Previous Message | Andres Freund | 2015-02-22 13:05:27 | Re: SSL renegotiation |