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
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 |