| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Indexed views? |
| Date: | 2004-09-08 13:57:56 |
| Message-ID: | 19692.1094651876@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2004-09-08 15:03:01 | Re: Making AFTER triggers act properly in PL functions |
| Previous Message | David Fetter | 2004-09-08 13:54:50 | Re: FYI: Fujitsu |