From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | andrew(at)supernews(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1541: Unusually long INSERT times after fresh |
Date: | 2005-03-19 16:18:49 |
Message-ID: | 20050319081725.M31370@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 18 Mar 2005, Tom Lane wrote:
> 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?
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).
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2005-03-19 16:53:57 | Re: BUG #1518: Conversions to (undocumented) SQL year-month |
Previous Message | Tom Lane | 2005-03-19 16:11:13 | Re: BUG #1517: SQL interval syntax is accepted by the parser, |