RE: Delay locking partitions during INSERT and UPDATE

From: "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com>
To: 'David Rowley' <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Delay locking partitions during INSERT and UPDATE
Date: 2019-01-21 00:09:32
Message-ID: 25C1C6B2E7BE044889E4FE8643A58BA963DC468C@G01JPEXMBKW03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

on Fri, 18 2019 at 19:41, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>Perhaps you're running with plan_cache_mode = force_custom_plan.
>You'll likely need it set to auto for these to pass.

Thank you.
I was running with plan_cache_mode = force_custom_plan.
When it set to auto, all tests are passed.

regards,

sho kato
> -----Original Message-----
> From: David Rowley [mailto:david(dot)rowley(at)2ndquadrant(dot)com]
> Sent: Friday, January 18, 2019 7:41 PM
> To: Kato, Sho/加藤 翔 <kato-sho(at)jp(dot)fujitsu(dot)com>
> Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>; David
> Rowley <dgrowley(at)gmail(dot)com>
> Subject: Re: Delay locking partitions during INSERT and UPDATE
>
> On Fri, 18 Jan 2019 at 19:08, sho kato <kato-sho(at)jp(dot)fujitsu(dot)com> wrote:
> > I confirmed that this patch improve performance by 10 times or more.
>
> Thanks for testing this out.
>
> > Also, I did make installcheck world, but test partition_prune failed.
> > However, this test case failed even before applying a patch, so this
> patch is not a problem.
> > One of the results is as follows.
> >
> > explain (analyze, costs off, summary off, timing off) execute ab_q1
> (2, 2, 3);
> > - QUERY PLAN
> > ----------------------------------------------------------
> > + QUERY PLAN
> > +------------------------------------------------------
> > Append (actual rows=0 loops=1)
> > - Subplans Removed: 6
> > -> Seq Scan on ab_a2_b1 (actual rows=0 loops=1)
> > - Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
> > + Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
> > -> Seq Scan on ab_a2_b2 (actual rows=0 loops=1)
> > - Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
> > + Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
> > -> Seq Scan on ab_a2_b3 (actual rows=0 loops=1)
> > - Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
> > -(8 rows)
> > + Filter: ((a >= 2) AND (a <= 2) AND (b <= 3))
> > +(7 rows)
>
> Perhaps you're running with plan_cache_mode = force_custom_plan.
> You'll likely need it set to auto for these to pass.
>
>
> --
> David Rowley http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2019-01-21 00:25:16 Re: Allowing extensions to find out the OIDs of their member objects
Previous Message Tom Lane 2019-01-21 00:08:11 Re: Changing SQL Inlining Behaviour (or...?)