From: | zz_11(at)mail(dot)bg |
---|---|
To: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: possible wrong query plan on pg 8.3.5, |
Date: | 2009-09-15 10:09:54 |
Message-ID: | 20090915130954.64v61s92low8gkoo@mail.bg |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Цитат от Віталій Тимчишин <tivv00(at)gmail(dot)com>:
> May be you have very bad disk access times (e.g. slow random access)? In
> this case everything should be OK while data in cache and awful, when not.
> Could you check disk IO speed && IO wait while doing slow & fast query.
>
No, I think all is ok with disks. On my test server I have 8 SATA in
RAID 10 and on my production server I have 16 SATA in RAID10 dedicated
for pg data and also 8 SATA in RAID 10 for OS and pg_x_log and I do
not have any IO wait.
It is true, disks are much slower compared to RAM.
> BTW: In this case, increasing shared buffers may help. At least this will
> prevent other applications & AFAIK sequence scans to move your index data
> from cache.
I will try to increase this value.
I think recomendation in docs was 1/4 from RAM, and on production
server I have it setup to 1/4 from RAM ( 32 GB).
Will os not cache the data from shared buffers for second time ?
The next step will be to move to pg 8.4, but I i twill tak etime for testing.
>
> Best regards, Vitalii Tymchyshyn
>
regards,
ivan.
-------------------------------------
http://www.tooway.bg/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrzej Zawadzki | 2009-09-15 11:13:43 | Re: CLUSTER and a problem |
Previous Message | std pik | 2009-09-15 09:27:41 | statistical table |