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

Поиск
Список
Период
Сортировка
От John Papandriopoulos
Тема Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Дата
Msg-id idfruc$aiq$1@news.hub.org
обсуждение исходный текст
Ответ на Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Список pgsql-performance
On 12/4/10 3:19 PM, Mladen Gogala wrote:
> Tom Lane wrote:
>> Partitioning using these techniques will work well with up to
>> perhaps a hundred partitions; don't try to use many thousands of
>> partitions.
>> regards, tom lane
> Hmmm, what happens if I need 10 years of data, in monthly partitions? It
> would be 120 partitions. Can you please elaborate on that limitation?
> Any plans on lifting that restriction?
>

Even with 1k partitions, I don't have any issues any of the SELECT, UPDATE or DELETE queries and with 8GB RAM.

I suppose if you're using INSERT triggers, you'd want to make sure your plpgsql function is fast: I'm partitioning by
power-of-two,so can use right-shift n-bits to quickly compute the insertion table name, rather than using an if-else-if
chain.

John

В списке 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