Re: BUG #1541: Unusually long INSERT times after fresh
| От | Stephan Szabo |
|---|---|
| Тема | Re: BUG #1541: Unusually long INSERT times after fresh |
| Дата | |
| Msg-id | 20050319081725.M31370@megazone.bigpanda.com обсуждение исходный текст |
| Ответ на | Re: BUG #1541: Unusually long INSERT times after fresh clean/CREATE TABLES (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
On Fri, 18 Mar 2005, Tom Lane wrote: > Andrew - Supernews <andrew+nonews@supernews.com> writes: > > It turns out that the scenario above is trivial to hit in 8.0 using > > referential constraints; RI triggers cache their plans, and on 8.0 the RI > > query is planned as a seqscan if the tables are freshly created. (On 7.4 > > the plan is an index scan, thanks to the default 1000 rows / 10 pages stats.) > > Hm. One thing we could do is to throw in some default values when we > see the table has exactly zero pages --- perhaps ye olde traditional > 1000/10, or possibly something else, but anyway not exactly 0/0. > > The reason I thought we didn't need to do this sort of hack anymore > is that pg_dump loads the tables first and then creates the RI > constraints. What exactly is the common case where the wrong thing > happens? Probably loading a schema only dump followed by a data load that doesn't turn off the constraint (as I believe that's non-default on data-only dumps now).
В списке pgsql-bugs по дате отправления: