| From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gary Doades" <gpd(at)gpdnet(dot)co(dot)uk>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: planner/optimizer question |
| Date: | 2004-04-29 17:03:03 |
| Message-ID: | pvc290584alms4s6hurvsh5ra09ki7se1s@email.aon.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 28 Apr 2004 09:05:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ ... visibility information in index tuples ... ]
>Storing that information would at least double the overhead space used
>for each index tuple. The resulting index bloat would significantly
>slow index operations by requiring more I/O. So it's far from clear
>that this would be a win, even for those who care only about select
>speed.
While the storage overhead could be reduced to 1 bit (not a joke) we'd
still have the I/O overhead of locating and updating index tuples for
every heap tuple deleted/updated.
Servus
Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manfred Koizar | 2004-04-29 17:13:49 | Re: Simply join in PostrgeSQL takes too long |
| Previous Message | Manfred Koizar | 2004-04-29 16:56:36 | Re: [HACKERS] Number of pages in a random sample |