Re: 7.4beta2 vs 7.3.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gaetano Mendola <mendola(at)bigfoot(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.4beta2 vs 7.3.3
Date: 2003-09-18 20:24:05
Message-ID: 2148.1063916645@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> ===== Bad news =====
> I posted time ago about a slow query:

> SELECT ul.*
> FROM user_logs ul,
> user_data ud,
> class_default cd
> WHERE ul.id_user = ud.id_user AND
> ud.id_class = cd.id_class AND
> cd.id_provider = 39;

I think the reason the planner chooses a not-optimal plan here is that
it's misestimating the number of rows involved by a factor of 10
(it thinks there will be 400 matching user_data rows, not 43).

You would probably find better results if you increase the statistics
target for user_data.id_class and re-ANALYZE. See past discussions in
pgsql-performance.

> Here the comparison between Postgres7.3.3 and
> Postgres7.4beta2 for that original query:

Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. Possibly you need to vacuum more often to keep down the
amount of junk in the tables.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Spraul 2003-09-18 21:26:49 Memory buffer alignment
Previous Message Tom Lane 2003-09-18 19:54:10 Re: Killing the backend to cancel a long waiting query