RE: Delay locking partitions during INSERT and UPDATE - Mailing list pgsql-hackers

From Kato, Sho
Subject RE: Delay locking partitions during INSERT and UPDATE
Date
Msg-id 25C1C6B2E7BE044889E4FE8643A58BA963DC468C@G01JPEXMBKW03
Whole thread Raw
In response to Re: Delay locking partitions during INSERT and UPDATE  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Delay locking partitions during INSERT and UPDATE
List pgsql-hackers
on Fri, 18 2019 at 19:41, David Rowley <david.rowley@2ndquadrant.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.rowley@2ndquadrant.com]
> Sent: Friday, January 18, 2019 7:41 PM
> To: Kato, Sho/加藤 翔 <kato-sho@jp.fujitsu.com>
> Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; David
> Rowley <dgrowley@gmail.com>
> Subject: Re: Delay locking partitions during INSERT and UPDATE
> 
> On Fri, 18 Jan 2019 at 19:08, sho kato <kato-sho@jp.fujitsu.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
> 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Changing SQL Inlining Behaviour (or...?)
Next
From: Andrew Gierth
Date:
Subject: Re: Allowing extensions to find out the OIDs of their member objects