From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Delay locking partitions during query execution |
Date: | 2019-01-03 21:50:24 |
Message-ID: | CAKJS1f9pMndi33DXdFYAPdeMPpWLQGOk_J=aGZ72vgaZXtzw6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 4 Jan 2019 at 02:40, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> I'm a bit confused, because I can't reproduce any such speedup. I've
> used the attached script that varies the number of partitions (which
> worked quite nicely in the INSERT thread), but I'm getting results like
> this:
>
> partitions 0 100 1000 10000
> --------------------------------------------
> master 49 1214 186 11
> patched 53 1225 187 11
>
> So I don't see any significant speedup, for some reason :-(
>
> Before I start digging into this, is there something that needs to be
> done to enable it?
Thanks for looking at this.
One thing I seem to quite often forget to mention is that I was running with:
plan_cache_mode = force_generic_plan
max_parallel_workers_per_gather = 0;
Without changing plan_cache_mode then the planner would likely never
favour a generic plan since it will not appear to be very efficient
due to the lack of consideration to the costing of run-time partition
pruning.
Also, then with a generic plan, the planner will likely want to build
a parallel plan since it sees up to 10k partitions that need to be
scanned. max_parallel_workers_per_gather = 0 puts it right.
(Ideally, the planner would cost run-time pruning, but it's not quite
so simple for RANGE partitions with non-equality operators. Likely
we'll want to fix that one day, but that's not for here)
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-03 22:03:43 | Re: Unified logging system for command-line programs |
Previous Message | Peter Eisentraut | 2019-01-03 21:49:55 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |