From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Ordered Partitioned Table Scans |
Date: | 2019-03-05 18:16:50 |
Message-ID: | CA+Tgmoa7pPXOd2w2hvQm8xD5EfNpvLgjSW9-TTgcWDbx1mzufA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 19, 2018 at 5:08 PM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> With my idea for using live_parts, we'll process the partitions
> looking for interleaved values on each query, after pruning takes
> place. In this case, we'll see the partitions are naturally ordered. I
> don't really foresee any issues with that additional processing since
> it will only be a big effort when there are a large number of
> partitions, and in those cases the planner already has lots of work to
> do. Such processing is just a drop in the ocean when compared to path
> generation for all those partitions.
I agree that partitions_are_ordered() is cheap enough in this patch
that it probably doesn't matter whether we cache the result. On the
other hand, that's mostly because you haven't handled the hard cases -
e.g. interleaved list partitions. If you did, then it would be
expensive, and it probably *would* be worth caching the result. Now
maybe those hard cases aren't worth handling anyway.
You also seem to be saying that since we run-time partitioning pruning
might change the answer, caching the initial answer is pointless. But
I think Julien has made a good argument for why that's wrong: if the
initial answer is that the partitions are ordered, which will often be
true, then we can skip all later checks.
So I am OK with the fact that this patch doesn't choose to cache it,
but I don't really buy any of your arguments for why it would be a bad
idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-05 18:19:17 | Re: Inheriting table AMs for partitioned tables |
Previous Message | Thomas Munro | 2019-03-05 18:05:55 | Re: Rare SSL failures on eelpout |