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
Ответ на
Список
Дерево обсуждения
Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared
to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT Mladen Gogala <mladen.gogala@vmsinfo.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT Mladen Gogala <mladen.gogala@vmsinfo.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Jochen Erwied <jochen@pgsql-performance.erwied.eu>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT Tom Lane <tgl@sss.pgh.pa.us>
Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
vmem compared to SELECT John Papandriopoulos <dr.jpap@gmail.com>
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
Дата:
От: Tom Lane
Дата: