To: Ruslan Zakirov <ruz@bestpractical.com>
cc: pgsql-performance@postgresql.org
Subject: Re: avoiding seq scans when two columns are very correlated 
In-reply-to: 
 <CAMOxC8vN4RzrzDEgWxXxdyfjCZfAzC8TbznakzmQE3q8=XL6sw@mail.gmail.com>
References: 
 <CAMOxC8vN4RzrzDEgWxXxdyfjCZfAzC8TbznakzmQE3q8=XL6sw@mail.gmail.com>
Comments: In-reply-to Ruslan Zakirov <ruz@bestpractical.com>
	message dated "Fri, 11 Nov 2011 19:01:41 +0400"
Date: Fri, 11 Nov 2011 10:36:26 -0500
Message-ID: <5467.1321025786@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ruslan Zakirov <ruz@bestpractical.com> writes:
> A table has two columns id and EffectiveId. First is primary key.
> EffectiveId is almost always equal to id (95%) unless records are
> merged. Many queries have id = EffectiveId condition. Both columns are
> very distinct and Pg reasonably decides that condition has very low
> selectivity and picks sequence scan.

I think the only way is to rethink your data representation.  PG doesn't
have cross-column statistics at all, and even if it did, you'd be asking
for an estimate of conditions in the "long tail" of the distribution.
That's unlikely to be very accurate.

Consider adding a "merged" boolean, or defining effectiveid differently.
For instance you could set it to null in unmerged records; then you
could get the equivalent of the current meaning with
COALESCE(effectiveid, id).  In either case, PG would then have
statistics that bear directly on the question of how many merged vs
unmerged records there are.

			regards, tom lane