From: | Kirit Parmar <kirit(dot)p(at)directi(dot)com> |
---|---|
To: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Karthik Iyer <karthik(dot)i(at)directi(dot)com>, Reinwald Warapen <reinwald(dot)w(at)directi(dot)com> |
Subject: | Re: DATA corruption after promoting slave to master |
Date: | 2014-11-07 17:39:53 |
Message-ID: | CAG5-jKrWoo7kkPfKm=1FOtifWUA2wBkVDbYKYPKMb0z=drx3GA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hey Shaun,
Thanks for quick reply
We have not changed the default_statistics_target, so it shall remain to
its default value 100.
I would like to share our observation on this if you can infer anything
from it. : It started using query plan 1 after a our scheduled vacuum run
and it continued to use the plan for a day till next day scheduled vacuum
run. it switched to optimal query plan 2 and slowness disappeared after
then.
However this is what we are thinking to do incase if resurface :
1. run vacuum analyse (assuming it will help to query planner to choose
best possible path as it updates the stats in pg_statistic).
2. If it does not work, increase the default_statistics_target for the
column.
Let us know your thoughts.
On Thu, Nov 6, 2014 at 7:39 PM, Shaun Thomas <sthomas(at)optionshouse(dot)com>
wrote:
> Hi Krit,
>
> It looks like your actual problem is here:
>
> > Index Scan using t1_orderid_creationtime_idx on t1
> > (cost=0.43..1181104.36 rows=9879754 width=158)
> > (actual time=0.021..60830.724 rows=2416614 loops=1
>
> This index scan estimates 9.8M rows, and had to touch 2.4M. The issue is
> that your LIMIT clause makes the planner overly optimistic. The worst case
> cost estimate for this part of the query is about 1.2M, which is much
> higher than the SEQ SCAN variation you posted. The planner must think it
> can get the rows without incurring the full cost, otherwise I can't see how
> the 1.2M cost estimate wasn't rolled into the total estimate.
>
> Unfortunately behavior like this is pretty common when using LIMIT
> clauses. Sometimes the planner thinks it can get results much faster than
> it actually can, and it ends up reading a much larger portion of the data
> than it assumed would be necessary.
>
> Just out of curiosity, Can you tell me what your default_statistics_target
> is?
>
> ______________________________________________
>
> See http://www.peak6.com/email_disclaimer/ for terms and conditions
> related to this email
>
--
Kirit Parmar
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim Gündüz | 2014-11-07 17:43:54 | Re: Testing on Power 8 systems |
Previous Message | David G Johnston | 2014-11-07 16:54:57 | Re: Fwd: function for trigger |