Re: [SQL] Trouble with massive select statement. - Mailing list pgsql-sql

From Tom Lane
Subject Re: [SQL] Trouble with massive select statement.
Date
Msg-id 19353.930065110@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SQL] Trouble with massive select statement.  (Darren Greer <dgreer@websightsolutions.com>)
List pgsql-sql
Darren Greer <dgreer@websightsolutions.com> writes:
> Now comes the other twist.  I already have a select statement (select
> first_name, email from listeners l, listeners_data ld where l.username
> = ld.username and $filter;).  The $filter is a bunch of and
> statements that limit the data coming from the table listeners.  I
> need to get the select statement you told me to work as a filter on
> the data that this select statement grabs.  I cant see an easy way to
> do this without making this thing incredibly slow having to chech
> every user.  Any thoughts?

This isn't very clear to me, but a couple of thoughts:

1. Rather than a subselect that gets re-executed for every tuple,
consider a temporary table:SELECT * FROM my_table INTO temp_table WHERE .... ;SELECT * FROM temp_table WHERE ... ;DROP
TABLEtemp_table ;
 
This is currently the only way to achieve results that require multiple
levels of grouping.

2. The system knows how to exploit indexes to avoid scanning all of a
table, if you have WHERE conditions of the right form.  For example,
given an index on test_date, "WHERE test_date > '05-14-1999'" won't
bother to scan tuples older than the specified date, and a two-way
constraint likeWHERE test_date > '05-14-1999' AND test_date < '05-21-1999'
is even more effective.  So, look at the filter conditions you expect
to use and consider making an index or two.  (Don't go overboard making
indexes, since you pay for them in extra work in table updates...)
        regards, tom lane


pgsql-sql by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [SQL] Create table doesn't always respect atomicity of transactions.
Next
From: Michael J Davis
Date:
Subject: RE: [SQL] ODBC SQL question