a_ogawa <[EMAIL PROTECTED]> writes:
> I remaked patch for "Cache last known per-tuple offsets to speed
> long tuple access" that is in TODO list.
I've applied this patch with some revisions (mostly to put the
functionality in places that seemed more appropriate than execQual.c).
Many thanks!
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
a_ogawa wrote:
>
> I remaked patch for "Cache last known per-tuple offsets to speed
> long tuple access" that is in TODO
I remaked patch for "Cache last known per-tuple offsets to speed
long tuple access" that is in TODO list.
The point of this patch is as follows:
(1)Add fields to TupleTableSlot and TupleTableData.
This fields are for holding the tuple disassembly information.
(2)Add the c
Thank you for advice.
I am going to remake a patch, in order to make it simple.
The plan of a new patch is as follows.
(1)Add fields to TupleTableSlot and TupleTableData.
This fields are for holding the tuple disassembly information.
(2)Add the codes which initializes/cle
a_ogawa <[EMAIL PROTECTED]> writes:
> I made a patch for "Cache last known per-tuple offsets to speed
> long tuple access" that is in TODO list.
> I referred URL below for implementation.
> http://archives.postgresql.org/pgsql-performance/2003-01/msg00262.php
This wasn't quite what I had in mind
I made a patch for "Cache last known per-tuple offsets to speed
long tuple access" that is in TODO list.
This problem was discussed on hackers-list as "Terrible performance
on wide selects".
The point of this problem is nocachegetattr() used from ExecEvalVar().
If tuple has
