Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4
Дата
Msg-id CA+TgmoagouLzj6bzb-wcQDqO2bsZ=0CRY1jay=vFtbzUbGde9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One thing that occurs to me is that if the generic plan estimate comes
> out much cheaper than the custom one, maybe we should assume that the
> generic's cost estimate is bogus.  Right offhand I can't think of a reason
> for a custom plan to look worse than a generic one, unless there's a
> statistical quirk like this one.

That's an interesting idea, but what do we do after deciding that it's
bogus?  The generic plan really can't be cheaper than the custom plan,
but it could be the same price, or as close as makes no difference.

I have long thought that maybe the custom vs. generic plan decision
should have something to do with whether the parameters are MCVs of
the table columns they're being compared against.  This case is
interesting because it demonstrates that querying for a *non*-MCV can
require a switch to a custom plan, which is something I don't think
I've seen before.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: using custom scan nodes to prototype parallel sequential scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: group locking: incomplete patch, just for discussion