From: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Equivalent praxis to CLUSTERED INDEX? |
Date: | 2004-08-28 01:02:47 |
Message-ID: | 412FD9B7.4080207@bigfoot.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>>Agreed. What I am wondering is with our system where every update gets
>>a new row, how would this help us? I know we try to keep an update on
>>the same row as the original, but is there any significant performance
>>benefit to doing that which would offset the compaction advantage?
>
>
> Because Oracle uses overwrite-in-place (undoing from an UNDO log on
> transaction abort), while we always write a whole new row, it would take
> much larger PCTFREE wastage to get a useful benefit in PG than it does
> in Oracle. That wastage translates directly into increased I/O costs,
> so I'm a bit dubious that we should assume there is a win to be had here
> just because Oracle offers the feature.
Mmmm. Consider this scenario:
ctid datas
(0,1) yyy-xxxxxxxxxxxxxxxxxxx
(0,2) -------- EMPTY --------
(0,3) -------- EMPTY --------
(0,4) -------- EMPTY --------
(0,5) -------- EMPTY --------
(0,6) yyy-xxxxxxxxxxxxxxxxxxx
(0,7) -------- EMPTY --------
.... -------- EMPTY --------
(0,11) yyy-xxxxxxxxxxxxxxxxxxx
the row (0,2) --> (0,5) are space available for the (0,1) updates.
This will help a table clustered ( for example ) to mantain his
own correct cluster order.
Regards
Gaetano Mendola
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2004-08-28 02:08:01 | Re: Equivalent praxis to CLUSTERED INDEX? |
Previous Message | Artimenko Igor | 2004-08-27 21:08:58 | Re: Why those queries do not utilize indexes? |