Another random idea - does PostgreSQL do any caching of query plans?
even on the session level?
I ran these queries from the same Query window, so my idea is that maybe
the inner join plan was cached prior to an automatic analyze being run.
But I'm doubting PostgreSQL would do something like that. And of
course, if PostgreSQL doesn't cache query plans - this idea is bogus =)
On Wed, 10 Jan 2007 13:38:24 -0500, "Jeremy Haile" <jhaile(at)fastmail(dot)fm>
> I'm pretty sure it didn't analyze in between - autovac is turned off
> and I ran the test multiple times before posting.
> But since I can't reproduce it anymore, I can't be 100% sure. And it
> certainly doesn't make sense that the estimate for the index scan would
> change based on an unrelated join condition.
> If I ever get it to happen again, I'll be more careful and repost if it
> is a real issue. Thanks for pointing me in the right direction!
> On Wed, 10 Jan 2007 13:38:15 -0500, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> said:
> > "Jeremy Haile" <jhaile(at)fastmail(dot)fm> writes:
> > > I still don't understand why the inner join would be so different from
> > > the left join prior to the analyze.
> > Are you sure you hadn't analyzed in between? Or maybe autovac did it
> > for you? The reason for the plan change is the change from estimating
> > 1 row matching the transaction_date range constraint, to estimating lots
> > of them, and the join type away up at the top would surely not have
> > affected that.
> > regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2007-01-10 19:22:35|
|Subject: Re: Slow inner join, but left join is fast |
|Previous:||From: Jeremy Haile||Date: 2007-01-10 18:38:24|
|Subject: Re: Slow inner join, but left join is fast|