Re: We need index-only scans

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We need index-only scans
Date: 2010-11-12 14:01:39
Message-ID: 4CDD48C3.2010300@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12.11.2010 15:51, Alvaro Herrera wrote:
> Excerpts from Greg Stark's message of vie nov 12 10:33:28 -0300 2010:
>
>> In Postgres, aside from the visibility issues we have a separate
>> problem. In order to achieve high concurrency we allow splits to occur
>> without locking the index. And the new pages can be found anywhere in
>> the index, even to the left of the existing page. So a sequential scan
>> could miss some data if the page it's on is split and some of the data
>> is moved to be to the left of where our scan is.
>
> Eh?

It took me a while to understand what Greg meant as well. You can't scan
a B-tree index in *physical order*, You have to first descend to the
leftmost leaf, and follow the right pointers from there until you reach
the rightmost leaf. That is a lot slower than seqscanning a file in
physical order.

We solved that for VACUUM, taking advantage of the fact that there can
only be one VACUUM on a table at a time. Maybe that mechanism could be
generalized to all scans, but it would require some thinking..

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-11-12 14:02:40 Re: duplicate connection failure messages
Previous Message Alvaro Herrera 2010-11-12 13:51:45 Re: We need index-only scans