| 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: | Whole Thread | Raw Message | 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
| 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 |