| 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: | Whole Thread | Raw Message | 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 |