Re: avoiding seq scans when two columns are very correlated

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: avoiding seq scans when two columns are very correlated
Дата
Msg-id 5467.1321025786@sss.pgh.pa.us
обсуждение исходный текст
Ответ на avoiding seq scans when two columns are very correlated  (Ruslan Zakirov <ruz@bestpractical.com>)
Ответы Re: avoiding seq scans when two columns are very correlated  (Ruslan Zakirov <ruz@bestpractical.com>)
Список pgsql-performance
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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ruslan Zakirov
Дата:
Сообщение: avoiding seq scans when two columns are very correlated
Следующее
От: Sorin Dudui
Дата:
Сообщение: where clause + function, execution order