Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
If there was more information than the tuplestore could keep in memory,
then a TIDstore might be faster, but only if it resulted in reading from
the heap sequentially, or very near it.
That's easily arranged, use a bitmap indexing data structure.
I think we could probably even live with the structure becoming lossy
under memory pressure: AFAICS, all rows modified by a single query ought
to have the same XMIN/CMIN (or XMAX/CMAX for deleted rows), so it should
be possible to verify whether a particular row is one of the interesting
ones or not.
I think the hard part of this task is designing the API for access to
the rowsets from triggers.
How expensive is this going to be, especially for huge numbers of rows?
Would it be done for all queries, or just those with a per statement
trigger, or only when explicitly requested?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
