Re: [SQL] Trouble with massive select statement.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dgreer(at)websightsolutions(dot)com
Cc: pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] Trouble with massive select statement.
Date: 1999-06-22 15:25:10
Message-ID: 19353.930065110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Darren Greer <dgreer(at)websightsolutions(dot)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 TABLE temp_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 like
WHERE 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

Browse pgsql-sql by date

  From Date Subject
Next Message Michael J Davis 1999-06-22 15:29:17 RE: [SQL] ODBC SQL question
Previous Message Bruce Momjian 1999-06-22 14:45:23 Re: [SQL] Create table doesn't always respect atomicity of transactions.