1 ) Limit (cost=0.00..9.57 rows=3 width=4) (actual time=*0.090..0.138*
rows=3 loops=1)
2 ) Limit (cost=0.00..12.76 rows=4 width=4) (actual
time=*0.091..4436.795* rows=4 loops=1)
1 ) -> Merge Join (cost=0.00..1098182.56 rows=344125 width=4)
(actual time=*0.088..0.136* rows=*3* loops=1)
2
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 plan.
exp
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
2010/4/10 Greg Smith :
> Scott Marlowe wrote:
>> For 2 sockets Intel rules the roost. I'd imagine AMD's much faster
>> bus architecture for >2 sockets would make them the winner, but I
>> haven't had a system like that to test, either Intel or AMD.
>>
>
> AMD has been getting such poor performance
Ľubomír Varga wrote:
> SELECT * FROM t_route
> WHERE t_route.route_type_fk = 1
> limit 4;
This one scanned the t_route table until it found four rows that
matched. It apparently didn't need to look at very many rows to find
the four matches, so it was fast.
> SELECT * FROM t_route
> WH
