Re: DATA corruption after promoting slave to master

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

In response to

Responses

Browse pgsql-general by date

  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