From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: btree split logic is fragile in the presence of large index items |
Date: | 2000-07-19 03:54:56 |
Message-ID: | 000801bff135$1a0d4060$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
>
> I've been chewing some more on the duplicate-key btree issue, and
> digging through CVS logs and Postgres v4.2 to try to understand the
> history of the code (and boy, this code does have a lot of history
> doesn't it?)
>
> One thing I'm still not too clear on is how we handle backwards
> indexscans. After looking at Lehman and Yao's paper it seems like
> only forward scans are guaranteed to work when other processes are
> busy splitting pages. Anybody know how that's handled?
>
There's the following comment for backwards scan in _bt_step()
in nbtsearch.c
/*
* If the adjacent page just split,
then
we may have
* the wrong block. Handle this
case.
Because pages
* only split right, we don't have
to wo
rry about this
* failing to terminate.
*/
Seems backwards index scans sometimes move right(scan forward).
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-07-19 03:56:35 | Re: PRIMARY KEY & INHERITANCE (fwd) |
Previous Message | Chris Bitmead | 2000-07-19 03:52:02 | Re: MySQL comparison |