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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux