From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |
Date: | 2005-03-23 21:26:55 |
Message-ID: | slrnd43nov.rhd.andrew+nonews@trinity.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-performance |
On 2005-03-23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
>> Changing the order so that the referenced table is fully populated, or at
>> least populated with more than a handful of pages of rows, before doing
>> _any_ insert on a referencing table in the same session will avoid the
>> misplan of the FK trigger queries, because when the first insert happens
>> on a referencing table, there will be no reason for the planner to prefer
>> a sequential scan. So this result is not surprising at all.
>
> I'm still looking for an example that demonstrates why this is a common
> problem that we need to worry about. ISTM that if an FK reference is
> hit when there are still zero entries in the referenced table, that
> insertion will fail anyway, and so people wouldn't try to load data in
> such an order.
Think "1 row", not "0 rows".
It is not reasonable to assume that _all_ cases of data loading (other than
perhaps the very largest) will be done by loading entire tables at a time,
especially when importing from external sources where the data is
differently structured.
> We could band-aid this in 8.0 as previously suggested (have the planner
> assume > 0 pages when it sees actually 0 pages) but without seeing a
> concrete example I can't tell if that will fix the complaint or not.
It won't; the problem is with 1 page, not 0.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2005-03-23 21:44:19 | Re: Precision and scale of numeric column reported as value |
Previous Message | Stephan Szabo | 2005-03-23 21:26:39 | Re: Precision and scale of numeric column reported as value |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-23 22:13:40 | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |
Previous Message | Keith Browne | 2005-03-23 20:55:07 | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |