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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)supernews(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1541: Unusually long INSERT times after fresh clean/CREATE TABLES
Date: 2005-03-19 04:45:17
Message-ID: 12573.1111207517@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andrew - Supernews <andrew+nonews(at)supernews(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2005-03-19 04:50:32 Re: BUG #1517: SQL interval syntax is accepted by the parser,
Previous Message Bruce Momjian 2005-03-19 03:24:22 Re: BUG #1518: Conversions to (undocumented) SQL year-month and