From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: index fragmentation on insert-only table with non-unique column |
Date: | 2016-06-05 19:28:47 |
Message-ID: | CAMkU=1xwGn+O0jhKsvrUrbW9MQp1YX0iB4Y-6h1mEz0ffBxK-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sun, Jun 5, 2016 at 9:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Claudio Freire <klaussfreire(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Streamsoft - Mirek Szajowski | 2016-06-07 07:31:47 | Locking concurrency: select for update vs update |
Previous Message | Tom Lane | 2016-06-05 16:03:58 | Re: index fragmentation on insert-only table with non-unique column |