Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

Поиск
Список
Период
Сортировка
От Mladen Gogala
Тема Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Дата
Msg-id 4CFAB972.5050806@vmsinfo.com
обсуждение исходный текст
Ответ на Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane wrote:
> Hmm.  Rules?  Triggers?  You seem to be assuming the problem is at the
> planner stage but I'm not sure you've proven that.
>
>             regards, tom lane
>
>
Hmmm, I vaguely recollect a similar thread, started by me, although with
fewer partitions. In my experience, planner doesn't do a very good job
with partitions, especially with things like "min" or "max" which should
not be resolved by a full table scan, if there are indexes on partitions.

--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com


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

Предыдущее
От: John Papandriopoulos
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT