Re: Preformance

From: Cees van de Griend <cees-list(at)griend(dot)xs4all(dot)nl>
To:
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Preformance
Date: 2002-02-03 12:10:04
Message-ID: 20020203131004.A14012@griend.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Feb 02, 2002 at 05:09:58PM -0500, Tom Lane wrote:
> Cees van de Griend <cees-list(at)griend(dot)xs4all(dot)nl> writes:
> > What can possible be the cause of the difference in preformance?
>
> Probably the VACUUM ANALYZE statistics changed just enough to push the
> planner into making the wrong choice. You could experiment with doing
> "set enable_nestloop to off" and then EXPLAIN to see what the plan and
> cost are; I'll bet that the estimated cost of the hash plan is now
> just fractionally more than that of the nestloop.
>
> Of course, the *true* costs are very different, which is why I consider
> this a planner estimation failure.

I have dumped the table, droped the table and put the dump back into the
database. Now the speed is as it should be (for the time being).

If I understand you explanation, a possible hack to circumvent this problem
could be to trick the planner into thinking that it should use the hash
scan method, by inserting dummy data into the tbl[XXX]Number.

Another possible fix is to execute 'SET enable_nestloop = OFF;' before every
query.

Is this correct?

> regards, tom lane

Regards,
Cees.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-02-03 16:43:00 Re: Preformance
Previous Message Jeff Martin 2002-02-03 04:51:04 Re: PostgreSQL transaction locking problem