Marc Cousin <cousinmarc@xxxxxxxxx> writes: > Le mardi 01 mars 2011 07:20:19, Tom Lane a écrit : >> It's worth pointing out that the only reason this effect is dominating >> the runtime is that you don't have any statistics for these toy test >> tables. If you did, the cycles spent using those entries would dwarf >> the lookup costs, I think. So it's hard to get excited about doing >> anything based on this test case --- it's likely the bottleneck would be >> somewhere else entirely if you'd bothered to load up some data. > Yes, for the same test case, with a bit of data in every partition and > statistics up to date, planning time goes from 20 seconds to 125ms for the 600 > children/1000 columns case. Which is of course more than acceptable. [ scratches head ... ] Actually, I was expecting the runtime to go up not down. Maybe there's something else strange going on here. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
