Here is an overview of the SITC method:
http://momjian.us/cgi-bin/pgsitc
A pretty fundamental problem is that the method assumes it's
OK to change the CTID of a live tuple (by swapping its item
pointer with some expired version). It is not --- this will break:
I am having
Ühel kenal päeval, K, 2006-06-28 kell 18:19, kirjutas Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Here is an overview of the SITC method:
http://momjian.us/cgi-bin/pgsitc
A pretty fundamental problem is that the method assumes it's OK to
change the CTID of a live tuple (by
On Thu, Jun 29, 2006 at 01:39:51AM +0300, Hannu Krosing wrote:
And anyway, ctid is a usable unique row identifier only within read-only
transactions, or not ?
Err, no. The ctid is the only identifer of a tuple in any case. When
you do a delete, the tuple to be deleted is indicated by the ctid
And anyway, ctid is a usable unique row identifier only within
read-only transactions, or not ?
actually for as long as no vacuum comes along. This would change
with SITC. (Maybe it would help to only reuse old versions of the same
row,
then anybody holding a ctid would at least be still
Martijn van Oosterhout kleptog@svana.org writes:
Tom - what do you think of the other related idea, that of reusing dead
index entries ?
Possibly workable for btree now that we do page-at-a-time index scans;
however I'm pretty hesitant to build any large infrastructure atop that
change until
Ühel kenal päeval, N, 2006-06-29 kell 12:35, kirjutas Tom Lane:
Martijn van Oosterhout kleptog@svana.org writes:
Tom - what do you think of the other related idea, that of reusing dead
index entries ?
Possibly workable for btree now that we do page-at-a-time index scans;
however I'm
Tom Lane wrote:
Another issue is that this would replace a simple hint-bit setting with
an index change that requires a WAL entry. There'll be more WAL traffic
altogether from backends retail-deleting index tuples than there would
be from VACUUM cleaning the whole page at once
Speaking of
On Thu, Jun 29, 2006 at 12:35:12PM -0400, Tom Lane wrote:
Another issue is that this would replace a simple hint-bit setting with
an index change that requires a WAL entry. There'll be more WAL traffic
altogether from backends retail-deleting index tuples than there would
be from VACUUM
Martijn van Oosterhout wrote:
One thing I am confused about, currently the ctid chain follows tuple
history so that transactions can find the latest version of any tuple,
even if the key fields have changed. This proposal breaks that, I'm not
sure how important that is though.
No, SITC
Martijn van Oosterhout wrote:
You can't truncate a tuple to just the header, or at least it's not
going to be very useful to do it, unless you can also move other tuples
to coalesce the free space on the page. Which means you need a
VACUUM-strength page lock. If you're trying to do this
Bruce Momjian [EMAIL PROTECTED] writes:
Here is an overview of the SITC method:
http://momjian.us/cgi-bin/pgsitc
A pretty fundamental problem is that the method assumes it's OK to
change the CTID of a live tuple (by swapping its item pointer with some
expired version). It is not --- this
11 matches
Mail list logo
