From: | "Jeremy Haile" <jhaile(at)fastmail(dot)fm> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow inner join, but left join is fast |
Date: | 2007-01-10 19:26:55 |
Message-ID: | 1168457215.31642.1168606495@webmail.messagingengine.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I did create and drop an index at some point while looking at this
issue. But I definitely reran both of the queries (and explains) after
the index was dropped, so I don't understand why there would be a
difference between the inner and left query plans. (which were run
back-to-back more than once) Anyways - I'll let you know if something
similar happens again.
Thanks,
Jeremy Haile
On Wed, 10 Jan 2007 14:22:35 -0500, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> said:
> "Jeremy Haile" <jhaile(at)fastmail(dot)fm> writes:
> > Another random idea - does PostgreSQL do any caching of query plans?
>
> Only if the client specifies it, either by PREPARE or the equivalent
> protocol-level message. I dunno what client software you were using,
> but I think few if any would PREPARE behind your back. Might be worth
> checking into though, if you've eliminated autovacuum.
>
> Actually there's another possibility --- did you create any indexes on
> the table in between? CREATE INDEX doesn't do a full stats update, but
> it does count the rows and update pg_class.reltuples. But it's hard to
> believe that'd have caused as big a rowcount shift as we see here ...
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2007-01-10 20:01:15 | Re: performance implications of binary placement |
Previous Message | Tom Lane | 2007-01-10 19:22:35 | Re: Slow inner join, but left join is fast |