On 23.12.2005, at 15:35 Uhr, Carlos Benkendorf wrote:
> I appreciate your suggestion but I think I´m misunderstanding
> something, the select statement should return at about 150.000
> rows, why 5 rows?
I have looked at the wrong lines of the explain ... statement. Sorry,
my fault. With that many lines, I doubt that my workaround will do
anything good ... :-/ I was just a little bit to fast ... looking at
to many different "explain ..." (or similar) statements in the last
weeks.
Sorry, my fault.
Other idea: have you tried ordering the rows in memory? Is that
faster? From now looking better at the explain result, it seems to
me, that the sorting takes most of the time:
Sort (cost=201296.59..201663.10 rows=146602 width=897) (actual
time=9752.555..10342.363 rows=167710 loops=1)
How large are the rows returned by your query? Do they fit completely
in the memory during the sort? If PostgreSQL starts switching to temp
files ... There was a discussion on that topic a few weeks ago ...
Perhaps this may help:
------------------------------
work_mem (integer)
Specifies the amount of memory to be used by internal sort
operations and hash tables before switching to temporary disk files.
The value is specified in kilobytes, and defaults to 1024 kilobytes
(1 MB). Note that for a complex query, several sort or hash
operations might be running in parallel; each one will be allowed to
use as much memory as this value specifies before it starts to put
data into temporary files. Also, several running sessions could be
doing such operations concurrently. So the total memory used could be
many times the value of work_mem; it is necessary to keep this fact
in mind when choosing the value. Sort operations are used for ORDER
BY, DISTINCT, and merge joins. Hash tables are used in hash joins,
hash-based aggregation, and hash-based processing of IN subqueries.
------------------------------
cug
