Re: index fragmentation on insert-only table with non-unique column - Mailing list pgsql-performance

From Jeff Janes
Subject Re: index fragmentation on insert-only table with non-unique column
Date
Msg-id CAMkU=1xwGn+O0jhKsvrUrbW9MQp1YX0iB4Y-6h1mEz0ffBxK-Q@mail.gmail.com
Whole thread Raw
In response to Re: index fragmentation on insert-only table with non-unique column  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: index fragmentation on insert-only table with non-unique column  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-performance
On Sun, Jun 5, 2016 at 9:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Claudio Freire <klaussfreire@gmail.com> writes:
>> So correlated index scans look extra favourable vs bitmap index scans
>> because bitmap heap scans consider random page costs sans correlation
>> effects (even though correlation applies to bitmap heap scans as
>> well).
>
> Really?  How?  The index ordering has nothing to do with the order in
> which heap tuples will be visited.


It is not the order itself, but the density.

If the index is read in a range scan (as opposed to =ANY scan), and
the index lead column is correlated with the table ordering, then the
parts of the table that need to be visited will be much denser than if
there were no correlation.  But Claudio is saying that this is not
being accounted for.


Cheers,

Jeff


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: index fragmentation on insert-only table with non-unique column
Next
From: Streamsoft - Mirek Szajowski
Date:
Subject: Locking concurrency: select for update vs update