Re: inheritance: planning time vs children number vs column number
От | Tom Lane |
---|---|
Тема | Re: inheritance: planning time vs children number vs column number |
Дата | |
Msg-id | 17604.1298993631@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: inheritance: planning time vs children number vs column number (Marc Cousin <cousinmarc@gmail.com>) |
Ответы |
Re: inheritance: planning time vs children number vs column number
Re: inheritance: planning time vs children number vs column number |
Список | pgsql-performance |
Marc Cousin <cousinmarc@gmail.com> 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
В списке pgsql-performance по дате отправления: