Re: [SQL] Trouble with massive select statement.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [SQL] Trouble with massive select statement.
Дата
Msg-id 19353.930065110@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [SQL] Trouble with massive select statement.  (Darren Greer <dgreer@websightsolutions.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [SQL] Create table doesn't always respect atomicity of transactions.
Следующее
От: Michael J Davis
Дата:
Сообщение: RE: [SQL] ODBC SQL question