I wrote:
> Well, with the increased (and much more accurate) rowcount estimate,
> the estimated cost of the nestloop naturally went up a lot: it's
> proportional to the number of rows involved. It appears that the
> estimated cost of the mergejoin actually went *down* quite a bit
> (else it'd have
John Arbash Meinel <[EMAIL PROTECTED]> writes:
> So the big issue is why does the planner think that a nested loop is
> going to be more expensive than a merge join. That I don't really know.
Well, with the increased (and much more accurate) rowcount estimate,
the estimated cost of the nestloop na
werner fraga wrote:
Certain queries on my database get slower after
running a VACUUM ANALYZE. Why would this happen, and
how can I fix it?
I am running PostgreSQL 7.4.2 (I also seen this
problem on v. 7.3 and 8.0)
Here is a sample query that exhibits this behaviour
(here the query goes from 1 secon
Certain queries on my database get slower after
running a VACUUM ANALYZE. Why would this happen, and
how can I fix it?
I am running PostgreSQL 7.4.2 (I also seen this
problem on v. 7.3 and 8.0)
Here is a sample query that exhibits this behaviour
(here the query goes from 1 second before VACUUM
AN