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: | Raw Message | Whole Thread | 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 |