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
>
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...?) |