Re: avoiding seq scans when two columns are very correlated

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ruslan Zakirov <ruz(at)bestpractical(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: avoiding seq scans when two columns are very correlated
Date: 2011-11-11 15:36:26
Message-ID: 5467.1321025786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ruslan Zakirov <ruz(at)bestpractical(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Sorin Dudui 2011-11-11 15:38:43 where clause + function, execution order
Previous Message Ruslan Zakirov 2011-11-11 15:01:41 avoiding seq scans when two columns are very correlated