MIME-Version: 1.0
In-Reply-To: <969.1465142638@sss.pgh.pa.us>
References: <20160524173914.GA11880@telsasoft.com>
 <CAMkU=1wsSEgByzYQ5uazD1gSsJh9RRYME6ehgJsUp3XcMm2Djg@mail.gmail.com>
 <20160525140034.GB21220@telsasoft.com>
 <CAGTBQpbqkQYRbnz-7MJEhCL9bRhaE3sX12LZh4YGh4m+xoUqYA@mail.gmail.com>
 <20160603235406.GN23616@telsasoft.com>
 <CAGTBQpZ+auG+KhcLghvTecm4-cGGgL8vZb5uA3=47K7kf9RgJw@mail.gmail.com>
 <969.1465142638@sss.pgh.pa.us>
From: Jeff Janes <jeff.janes@gmail.com>
Date: Sun, 5 Jun 2016 12:28:47 -0700
Message-ID: 
 <CAMkU=1xwGn+O0jhKsvrUrbW9MQp1YX0iB4Y-6h1mEz0ffBxK-Q@mail.gmail.com>
Subject: Re: index fragmentation on insert-only table with
 non-unique column
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Claudio Freire <klaussfreire@gmail.com>,
 Justin Pryzby <pryzby@telsasoft.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance