From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | Istvan Endredy <istvan(dot)endredy(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad planning with 75% effective_cache_size |
Date: | 2012-04-18 06:51:19 |
Message-ID: | CABWW-d0bmpNXuztM=JT9+nGCOfYpCcwR7q20Or17VuXnvoMy=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
How about
with par_ as (select * from product_parent where parent_name like 'aa%' )
select distinct product_code from product p_
inner join par_ on p_.parent_id=par_.id
limit 2
?
2012/4/3 Istvan Endredy <istvan(dot)endredy(at)gmail(dot)com>
> Hi,
>
> i've ran into a planning problem.
>
>
> select distinct product_code from product p_
> inner join product_parent par_ on p_.parent_id=par_.id
> where par_.parent_name like 'aa%' limit 2
>
>
> If effective_cache_size is smaller (32MB), planning is ok and query is
> fast. (10ms)
> In the worst case (effective_cache_size=6GB) the speed depends on the
> value of 'limit' (in select): if it is smaller, query is slower. (12ms)
>
>
>
--
Best regards,
Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Eyal Wilde | 2012-04-18 07:32:07 | Re: scale up (postgresql vs mssql) |
Previous Message | Віталій Тимчишин | 2012-04-17 17:12:26 | Re: SeqScan with full text search |