Greg Stark <[EMAIL PROTECTED]> writes:
> Hm. Just thinking aloud here. But what if there was an option to store the
> visibility information separately from the heap entirely. There would still
> only be one copy of the visibility information and it wouldn't increase
> storage or i/o requirements.
How do you figure that it wouldn't increase I/O? In most scenarios that
would be still another block to read in to find out whether a tuple is
valid. (And that's assuming that you don't need any fancy indexing
scheme to associate tuples with visibility records.)
> But if the table has particularly wide records, then it might be useful to
> avoid having to read in the many blocks of records.
I think the TOAST scheme already gets much of the low-hanging fruit
here. It might be interesting to expose more TOAST control knobs,
though --- for instance make the thresholds settable per-table.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
