From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mason Harding <mason(dot)harding(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow SQL lookup due to every field being listed in SORT KEY |
Date: | 2010-09-11 02:00:38 |
Message-ID: | 5323.1284170438@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mason Harding <mason(dot)harding(at)gmail(dot)com> writes:
> Hi all. I Have the following query (tested in postgres 8.4 and 9.0rc1)
> SELECT distinct event0_.*
> FROM event event0_ inner join account account1_ on
> event0_.account_id_owner=account1_.account_id
> LEFT OUTER JOIN friend friendcoll2_ ON
> account1_.account_id=friendcoll2_.friend_account_id
> WHERE (event0_.account_id_owner=2 or friendcoll2_.account_id=2
> AND friendcoll2_.status=2 AND (event0_.is_recomended is null OR
> event0_.is_recomended=false))
> ORDER BY event0_.event_id DESC LIMIT 25
> None of the tables listed here have more than a couple of thousand rows, and
> are all indexed. If I run that query as is, it will take up to 5 seconds,
> if I remove the ORDER BY and LIMIT, it will run into about 200 ms.
The reason it's sorting by all the columns is the DISTINCT: that's
implemented by a sort-and-unique type of scheme so it has to be sure
that all the columns are sorted. You didn't show the non-ORDER-BY
plan, but I suspect it's preferring a hash aggregation approach to
doing the DISTINCT if it doesn't have to produce sorted output.
The easiest way to make that query faster would be to raise work_mem
enough so that the sort doesn't have to spill to disk.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2010-09-11 02:03:37 | Re: Slow SQL lookup due to every field being listed in SORT KEY |
Previous Message | Stephen Frost | 2010-09-11 01:59:03 | Re: Slow SQL lookup due to every field being listed in SORT KEY |