Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location
Date: 2016-08-18 21:04:52
Message-ID: CACjxUsPSuHf3Gjuu=6=8ufnXTjSd8VFvU9goKfU2=h4hbioD=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 18, 2016 at 3:41 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:

> It also makes index scans of the form
>
> SELECT * FROM t WHERE some_col = some_const;
>
> Scan the heap in sequential order, even if some_col has low
> cardinality (ie: the query returns lots of tuples), which is a nice
> performance side effect.

Speaking of performance side effects, does this avoid O(N^2)
performance on index tuple insertion with duplicate values, for all
insertion orderings? For example, does it descend directly to the
right leaf page for the insert rather than starting at the front of
the block of duplicate values and scanning to the right for a
block with space, with a random chance to split a full block on
each page it moves through?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-18 21:07:47 Re: Improving planner's checks for parallel-unsafety
Previous Message Jeff Janes 2016-08-18 21:03:24 distinct estimate of a hard-coded VALUES list