| From: | Christo Du Preez <christo(at)mecola(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: test / live environment, major performance difference |
| Date: | 2007-06-12 16:59:16 |
| Message-ID: | 466ED0E4.3040803@mecola.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Yes, I have just about tried every combination of vacuum on the
database. Just to make 100% sure.
Tom Lane wrote:
> Christo Du Preez <christo(at)mecola(dot)com> writes:
>
>> On my laptop the explain analyze looks like this:
>>
>
>
>> "Index Scan using fki_layertype_parentid on layertype (cost=0.00..8.27
>> rows=1 width=109)"
>> " Index Cond: (parentid = 300)"
>>
>
> OK ...
>
>
>> and on the problem server:
>>
>
>
>> "Seq Scan on layertype (cost=0.00..20.39 rows=655 width=110)"
>> " Filter: (parentid = 300)"
>>
>
> The server thinks that every row of the table matches the WHERE clause.
> That being the case, it's making the right choice to use a seqscan.
> The question is why is the rows estimate so far off? Have you ANALYZEd
> the table lately?
>
> regards, tom lane
>
>
>
--
Christo Du Preez
Senior Software Engineer
Mecola IT
Mobile: +27 [0]83 326 8087
Skype: christodupreez
Website: http://www.locateandtrade.co.za
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-06-12 17:37:49 | Re: test / live environment, major performance difference |
| Previous Message | Sabin Coanda | 2007-06-12 16:42:10 | Re: VACUUM vs auto-vacuum daemon |