Re: BUG #1541: Unusually long INSERT times after fresh clean/CREATE TABLES

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #1541: Unusually long INSERT times after fresh clean/CREATE TABLES
Дата
Msg-id 12573.1111207517@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #1541: Unusually long INSERT times after fresh clean/CREATE TABLES  (Andrew - Supernews <andrew+nonews@supernews.com>)
Ответы Re: BUG #1541: Unusually long INSERT times after fresh  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список pgsql-bugs
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?

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #1518: Conversions to (undocumented) SQL year-month and
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #1517: SQL interval syntax is accepted by the parser,