| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Update on sort-compression stuff |
| Date: | 2006-05-23 18:27:11 |
| Message-ID: | 17147.1148408831@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> - Test a way of storing tuples with less overhead than a HeapTuple
> header. If you could do it for in-memory sorts, that'd mean you could
> fit more tuples in memory before spilling to disk. Given the
> "compression" in that case is extremely cheap, it'd be much more likely
> to be beneficial.
I looked into this and decided that trimming the headers for the
in-memory copies is not as attractive as all that. The killer problem
is that comparetup_heap() needs to be able to apply heap_getattr() to
the stored tuples to extract sort keys. Unless we want to support a
variant copy of the heap_getattr() infrastructure just for sort tuples,
it ain't gonna work. Another issue is that we'd be increasing the
palloc traffic for in-memory sorts, because tuplesort_gettuple() would
have to cons up a freshly palloc'd complete tuple to hand back to the
caller.
However, we can definitely trim a lot of overhead from what gets written
to "tape", so I'll have a go at doing that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2006-05-23 18:51:44 | Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1) |
| Previous Message | Jim C. Nasby | 2006-05-23 18:08:47 | Re: [GENERAL] autovacuum "connections" are hidden |