Re: slowness when subselect uses DISTINCT

From: "Phillip Smith" <phillip(dot)smith(at)weatherbeeta(dot)com(dot)au>
To: "'Stuart McGraw'" <smcg2297(at)frii(dot)com>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: slowness when subselect uses DISTINCT
Date: 2007-04-18 22:43:49
Message-ID: 002a01c7820b$07ee3010$9b0014ac@wbaus090
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

May I suggest you post an EXPLAIN ANALYZE to the group for the query you're
having problems with...?

-----Original Message-----
From: pgsql-sql-owner(at)postgresql(dot)org [mailto:pgsql-sql-owner(at)postgresql(dot)org]
On Behalf Of Stuart McGraw
Sent: Thursday, 19 April 2007 04:17
To: pgsql-sql(at)postgresql(dot)org
Subject: [SQL] slowness when subselect uses DISTINCT

I have several times now run into what seems
like similar performance problems with some
of my postgresql queries.

I have a view that runs reasonably quicky.

I use this view in a subselect in another
query and that query too runs reasonably
quicky.

The view returns some unwanted duplicate
rows so I modify it using either DISTINCT
or GROUP BY to eliminate them.
View still runs reasonably quickly.

I use the modified view as a subselect as
above, but now the query runs 2-3 orders
of magnitude more slowly than before.

Before I go through the effort of putting
together a specific and concise test case,
has anyone seen this general pattern and
have an explanation or advice? (PG-8.2.3)

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to
the addressee. If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message sql4-en 2007-04-19 06:08:27 Re: We all are looped on Internet: request + transport = invariant
Previous Message Stuart McGraw 2007-04-18 18:16:38 equiv of ascii() function for unicode?