2009/4/18 Tom Lane :
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
>> That expected 1510 rows in 'assigments' seems to be pretty off,
>
> The planner does not trust an empty table to stay empty. Every
> Postgres version in living memory has acted like that; it's not
> new to 8.4.
ok, thanks
Qui
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> That expected 1510 rows in 'assigments' seems to be pretty off,
The planner does not trust an empty table to stay empty. Every
Postgres version in living memory has acted like that; it's not
new to 8.4.
regards, tom lane
--
crawler=# select * from assigments;
jobid | timeout | workerid
---+-+--
(0 rows)
Time: 0.705 ms
crawler=# \d+ assigments
Table "public.assigments"
Column | Type |Modifiers
|
On Thu, 16 Apr 2009, Tom Lane wrote:
Matthew, can you put together a self-contained test case with a similar
slowdown?
I have done a bit of investigation, and I think I might have found the
smoking gun I was looking for. I just added a load of debug to the gist
consistent function on the bios
Tom Lane wrote:
Kris Jurka writes:
The hash join takes less than twenty seconds, the other two joins I
killed after five minutes. I can try to collect explain analyze results
later today if you'd like.
Attached are the explain analyze results. The analyze part hits the
hash join worst o
Tom Lane wrote:
Is there another issue here besides that one? I think you were hoping
that the hash join would be faster than the alternatives, but the cost
estimate says it's a lot slower. Is that actually the case?
The hash join takes less than twenty seconds, the other two joins I
kille
Kris Jurka writes:
> The hash join takes less than twenty seconds, the other two joins I
> killed after five minutes. I can try to collect explain analyze results
> later today if you'd like.
Please, unless the test case you already posted has similar behavior.
regards
Kris Jurka writes:
> So the default disable_cost isn't enough to push it to use the hash join
> plan and goes back to nestloop. Since disable_cost hasn't been touched
> since January 2000, perhaps it's time to bump that up to match today's
> hardware and problem sizes?
I think disable_cost wa
