Re: Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD)
Дата
Msg-id 1603.1433187085@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Once you're down to an estimate of one row retrieved, adding
>  Tom> additional index conditions simply increases the cost (not by
>  Tom> much, but it increases) without delivering any visible benefit.

> OK, but this is a serious problem because "estimate of one row" is a
> very common estimation failure mode, and isn't always solvable in the
> sense of arranging for better estimates (in the absence of hints, ugh).

Yeah.  I've occasionally wondered about removing the clamp-to-one-row
behavior, so that additional conditions would still look like they
contributed something (ie, 0.1 row is better than 1 row).  However,
that seems likely to break about as many cases as it fixes :-(.

A variant of that would be to only allow the minimum to be 1 row if
we are absolutely certain that's what we'll get (eg, we're searching
on a unique-key equality condition), and otherwise clamp to at least
2 rows.  Again though, this would be destabilizing lots of cases that
work well today.

I doubt there are any simple solutions here.
        regards, tom lane



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

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: Really bad blowups with hash outer join and nulls
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Multixid hindsight design