Re: Question about explain of index scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about explain of index scan
Date: 2005-09-04 22:21:51
Message-ID: 9021.1125872511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)skype(dot)net> writes:
> On R, 2005-09-02 at 11:03 -0400, Tom Lane wrote:
>> I once started to make a btree opclass for XID, and stopped when it
>> occurred to me that XID comparison doesn't obey the transitive law.
>> btree won't like that...

> Does this mean that Slony's usage of btree index on XID gives
> (occasionally) wrong results ?

I seem to recall some discussion of that in the archives (but can't find
it right now). If they do actually make btree indexes on XIDs then they
are probably broken.

XID comparison works OK as long as you make sure that all the XIDs
extant in the system at any one time are within +/- 2 billion of each
other, and so transitivity does hold within that subset. The problem
with a btree is that upper-level tree nodes are likely to contain page
boundary keys copied from data that vanished some time ago from the
underlying table. VACUUM-like techniques can guarantee that the
underlying table is free of old XIDs before the wraparound horizon is
reached, but I don't know how much extra safety margin is needed to
guarantee no inconsistencies inside a btree index (if indeed any such
guarantee is possible at all).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-09-04 22:37:14 Re: Question about explain of index scan
Previous Message Tom Lane 2005-09-04 22:06:11 Re: Proof of concept COLLATE support with patch