Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Дмитрий Фефелов
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id 201002111226.15967.fozzy@ac-sw.com
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> The only case that I think still has any merit is where you get a
> significantly better plan with known parameter values than without.
> The projected-cost threshold might be a reasonable approach for
> attacking that, ie, if estimated cost of generic plan exceeds X
> then take the time to build a custom plan instead.  I'm not sure that
> really will fix the problem, but it would be a very simple change to
> make to see how much it helps people.
> 
>             regards, tom lane
> 

It will definitely help with partitioned tables. It's very common case when 
raw data taken from hardware stored in single table first, and later we start 
to make partitions for each month/week/day. Feature can improve performance 
transparently to client apps.

regards, 
Dmitry

> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 


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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: knngist patch support
Следующее
От: Tom Lane
Дата:
Сообщение: Re: knngist patch support