On Sun, 2010-04-11 at 23:12 +0200, Corin wrote:
> Hi,
>
> I'm having a query where the planer chooses a very bad plan.
>
> explain analyze SELECT * FROM "telegrams" WHERE ((recipient_id=508933
> AND recipient_deleted=FALSE) OR (user_id=508933 AND user_deleted=FALSE))
> ORDER BY id DESC LIMIT 10
explain analyze SELECT * FROM "telegrams" WHERE ((recipient_id=508933
AND recipient_deleted=FALSE) OR (user_id=508933 AND user_deleted=FALSE))
ORDER BY id DESC LIMIT 10 OFFSET 0
If you need very fast performance on this query, you need to be able to
use the index for ordering.
Note that
On Sun, Apr 11, 2010 at 4:41 PM, Corin wrote:
> On 11.04.2010 23:18, Scott Marlowe wrote:
>>
>> In both instances your number of rows estimated is WAY higher than the
>> actual number of rows returned. Perhaps if you increased
>> default_statistics_target to 100, 200, 500 etc. re-analyzed, and th
On 11.04.2010 23:22, Luke Lonergan wrote:
Try random_page_cost=100
Increasing random_page_const to 100 (it was 2.5 before) did not help,
but lowering it <=1.5 helped.
As almost the whole dataset fit's into memory, I think I'll change it
permanently to 1.5 (seq_page is 1.0).
I'll also inc
On 11.04.2010 23:18, Scott Marlowe wrote:
In both instances your number of rows estimated is WAY higher than the
actual number of rows returned. Perhaps if you increased
default_statistics_target to 100, 200, 500 etc. re-analyzed, and then
reun explain analyze again.
Also increasing work_mem mi
Try random_page_cost=100
- Luke
- Original Message -
From: pgsql-performance-ow...@postgresql.org
To: pgsql-performance@postgresql.org
Sent: Sun Apr 11 14:12:30 2010
Subject: [PERFORM] planer chooses very bad plan
Hi,
I'm having a query where the planer chooses a very bad
On Sun, Apr 11, 2010 at 3:12 PM, Corin wrote:
> Hi,
>
> I'm having a query where the planer chooses a very bad plan.
In both instances your number of rows estimated is WAY higher than the
actual number of rows returned. Perhaps if you increased
default_statistics_target to 100, 200, 500 etc. re-
Hi,
I'm having a query where the planer chooses a very bad plan.
explain analyze SELECT * FROM "telegrams" WHERE ((recipient_id=508933
AND recipient_deleted=FALSE) OR (user_id=508933 AND user_deleted=FALSE))
ORDER BY id DESC LIMIT 10 OFFSET 0
"Limit (cost=0.00..1557.67 rows=10 width=78) (ac
