| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | josh(at)agliodbs(dot)com |
| Cc: | "Brian O'Reilly" <fade(at)deepsky(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |
| Date: | 2005-03-22 01:59:19 |
| Message-ID: | 3846.1111456759@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> I don't think your experience on this one query is descriptive of PostgreSQL
> in general. What I'm saying is that you most likely have a tuning problem,
> not a bug.
It might be a bug (or at least an unhelpful behavior) but the given case
didn't prove a thing. I'm still looking for an explanation of a common
case in which we'll cache a plan chosen too soon. I don't think
ordinary data loading situations will cause that problem. Choosing a
plan for an FK reference check while the referenced table is still empty
means that you're loading the tables in the wrong order, and your load
is going to fail anyhow.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Keith Browne | 2005-03-22 03:09:36 | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |
| Previous Message | Josh Berkus | 2005-03-22 01:53:16 | Re: BUG #1552: massive performance hit between 7.4 and 8.0.1 |