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 по дате отправления: