On Wed, Feb 21, 2018 at 2:36 PM, David Rowley
wrote:
> I've attached v11 of the patch.
>
Hi,
I have applied attached patch on head
"6f1d723b6359507ef55a81617167507bc25e3e2b" over Amit's v30 patches. while
testing further I got a server crash with below test case. Please take a
look.
CREATE TAB
On 20 February 2018 at 23:46, Rajkumar Raghuwanshi
wrote:
> I have applied v10 patch on Amit's v27 over head ad7dbee36. I got "ERROR:
> partition missing from Append subplans" with the patch. on head and only
> with Amit's patches query is working fine, Please find test case below.
Thanks for the
On Sat, Feb 17, 2018 at 2:27 PM, David Rowley
wrote:
> Hi,
>
> I've attached an updated patch, now at v10. v9 was short lived due to
> the evolution of Amit's which which this based on.
>
> This version is based on Amit's v27 of faster partition pruning [1]
> which can be applied atop of ad7dbee3
Hi,
I've attached an updated patch, now at v10. v9 was short lived due to
the evolution of Amit's which which this based on.
This version is based on Amit's v27 of faster partition pruning [1]
which can be applied atop of ad7dbee36.
I've done a self review of this, but I've not yet done any fina
On Tue, Jan 9, 2018 at 2:24 PM, Beena Emerson wrote:
> prepare abc_q1 (int, int, char) as select * from ab_c where a BETWEEN
> $1 and $2 AND b <= $3;
>
> --after 5 runs: abc_a2_b3 is not pruned.
This seems to be down to an existing bug. I'm not yet sure if it's
caused by faster_partition_prune_v1
On 9 January 2018 at 22:22, Beena Emerson wrote:
> ERROR: operator 1057 is not a member of opfamily 1976
Thanks for finding these. I'm looking into the above, and the other
ones you've mentioned now.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
Hi,
The mail was accidently sent before I could complete.
On Tue, Jan 9, 2018 at 2:24 PM, Beena Emerson wrote:
> Hello,
>
> The pruning does not work well with char type:
>
> Case 2: Case with optimizer pruning
> drop table ab_c;
> create table ab_c (a int not null, b int) partition by list(a);
Hello,
On Sun, Jan 7, 2018 at 5:31 PM, David Rowley
wrote:
> On 7 January 2018 at 00:03, David Rowley wrote:
>> I've fixed this in the attached, but I did so by calling
>> adjust_appendrel_attrs() from the nodeAppend.c, which did, of course,
>> mean that the AppendRelInfo needed to be given to t
On 7 January 2018 at 00:03, David Rowley wrote:
> I've fixed this in the attached, but I did so by calling
> adjust_appendrel_attrs() from the nodeAppend.c, which did, of course,
> mean that the AppendRelInfo needed to be given to the executor. I was
> also a bit unsure what exactly I should be do
Hello,
On Fri, Jan 5, 2018 at 6:24 AM, David Rowley
wrote:
> On 5 January 2018 at 05:37, Alvaro Herrera wrote:
>> I tried this patch (applying it on Amit's last current version on top of
>> 4e2970f8807f which is the latest it applies to) and regression tests
>> fail with the attached diff; in al
David Rowley wrote:
> Looks like it's down to ExplainPropertyFloat() having
> machine-dependent behaviour.
>
> On the machine that I was working with when testing this the following
> code outputs "1"
> [ sample code ]
>
> but on your machine it must be outputting "0"?
Yeah, it does. Thanks fo
On 5 January 2018 at 05:37, Alvaro Herrera wrote:
> I tried this patch (applying it on Amit's last current version on top of
> 4e2970f8807f which is the latest it applies to) and regression tests
> fail with the attached diff; in all cases it appears to be an off-by-one
> in row count. Would you
On 5 January 2018 at 05:37, Alvaro Herrera wrote:
> I tried this patch (applying it on Amit's last current version on top of
> 4e2970f8807f which is the latest it applies to) and regression tests
> fail with the attached diff; in all cases it appears to be an off-by-one
> in row count. Would you
I tried this patch (applying it on Amit's last current version on top of
4e2970f8807f which is the latest it applies to) and regression tests
fail with the attached diff; in all cases it appears to be an off-by-one
in row count. Would you please give it a look?
--
Álvaro Herrerah
On 1 January 2018 at 19:22, Beena Emerson wrote:
> I think you are testing without asserts
Yeah, I was indeed. Oops.
> The following assert fails: src/backend/optimizer/plan/setrefs.c :
> set_plan_refs: ln 921
> Assert(splan->plan.qual == NIL);
> Append node now has runtime partition quals.
>
>
Hello David,
On Wed, Dec 27, 2017 at 8:36 AM, David Rowley
wrote:
> Hi,
>
> Please find attached my 4th version this patch.
Thanks for the patch
>
> This is now based on v17 of Amit's faster partition pruning patch [1].
> It also now includes Beena's tests which I've done some mostly
> cosmetic
Hi,
Please find attached my 4th version this patch.
This is now based on v17 of Amit's faster partition pruning patch [1].
It also now includes Beena's tests which I've done some mostly
cosmetic changes to.
I've also fixed a few bugs, one in a case where I was not properly
handling zero matching
On Thu, Dec 21, 2017 at 8:37 PM, David Rowley
wrote:
>> No, I don't think comparing to previous custom plans is a workable
>> approach. I was thinking, rather, that if we know for example that
>> we've doing pruning on partition_column = $1, then we know that only
>> one partition will match. Th
On 22 December 2017 at 14:29, Robert Haas wrote:
> On Thu, Dec 21, 2017 at 6:53 PM, David Rowley
> wrote:
>> Are you considering some sort of clauselist_selectivity() estimate on
>> the given parameters and comparing that to the same selectivities that
>> were determined for the previous custom p
On Thu, Dec 21, 2017 at 6:53 PM, David Rowley
wrote:
> On 22 December 2017 at 12:45, Robert Haas wrote:
>> PREPARE q3 (int, int) AS SELECT * FROM unpartitioned_table WHERE
>> partkey BETWEEN $1 AND $2;
>>
>> ...that has to decide whether to use an index. And to do that it has
>> to estimate what
On 22 December 2017 at 12:45, Robert Haas wrote:
> PREPARE q3 (int, int) AS SELECT * FROM unpartitioned_table WHERE
> partkey BETWEEN $1 AND $2;
>
> ...that has to decide whether to use an index. And to do that it has
> to estimate what fraction of the table will match the BETWEEN clause.
> That
On 22 December 2017 at 03:02, Beena Emerson wrote:
> This seems like having two different patches for the same feature. I
> will post my version of the patch which uses the struct
> PartitionPruneInfo from your patch and I will add the other additional
> features you added like optimizing the prun
On Thu, Dec 21, 2017 at 4:01 AM, David Rowley
wrote:
> The problem is down to the logic in choose_custom_plan() only choosing
> a generic plan if the average cost of the generic plan is less than
> the average custom plan cost. The problem is that the generic plan can
> have many extra Append subn
On 22 December 2017 at 03:02, Beena Emerson wrote:
> postgres=# create table ta (a int not null) partition by list (a);
> CREATE TABLE
> postgres=# create table ta1 partition of ta for values in(1,2);
> CREATE TABLE
> postgres=# create table ta2 partition of ta for values in(3,4);
> CREATE TABLE
>
Hello,
On Thu, Dec 21, 2017 at 6:26 PM, David Rowley
wrote:
> On 21 December 2017 at 22:01, David Rowley
> wrote:
>> I've attached the latest version of the patch. This is based
>> on Amit's v15 of faster-partition-pruning [1] which I found to cleanly
>> apply to f94eec490
>
> Well, that went o
On 22 December 2017 at 02:06, Beena Emerson wrote:
>> Thanks for sending. Will the tests still pass if you remove the hack
>> from choose_custom_plan()?
>>
>
> The hack has been removed in the v7 patch sent and yes the tests work
> without any additional adjustments.
Oh nice. I see you've includ
Hello,
On Thu, Dec 21, 2017 at 6:30 PM, David Rowley
wrote:
> On 22 December 2017 at 01:43, Beena Emerson wrote:
>>> I wonder if Robert understands the extent of the problem. The patch
>>> will be useful to prune away partitions when the partitioned table is
>>> on the inside of a parameterised
On 22 December 2017 at 01:43, Beena Emerson wrote:
>> I wonder if Robert understands the extent of the problem. The patch
>> will be useful to prune away partitions when the partitioned table is
>> on the inside of a parameterised nested loop join, but I think we'll
>> likely get some complaints a
On 21 December 2017 at 22:01, David Rowley wrote:
> I've attached the latest version of the patch. This is based
> on Amit's v15 of faster-partition-pruning [1] which I found to cleanly
> apply to f94eec490
Well, that went out of date pretty quickly. Amit has now posted v16 of
the faster partitio
Hello,
On Thu, Dec 21, 2017 at 6:01 PM, David Rowley
wrote:
> On 21 December 2017 at 23:51, Beena Emerson wrote:
>> On Thu, Dec 21, 2017 at 2:31 PM, David Rowley
>> wrote:
>>> On 19 December 2017 at 21:54, Beena Emerson wrote:
>>
>>> The problem is down to the logic in choose_custom_plan() onl
On 21 December 2017 at 23:51, Beena Emerson wrote:
> On Thu, Dec 21, 2017 at 2:31 PM, David Rowley
> wrote:
>> On 19 December 2017 at 21:54, Beena Emerson wrote:
>
>> The problem is down to the logic in choose_custom_plan() only choosing
>> a generic plan if the average cost of the generic plan
Hello David,
On Thu, Dec 21, 2017 at 2:31 PM, David Rowley
wrote:
> On 19 December 2017 at 21:54, Beena Emerson wrote:
> The problem is down to the logic in choose_custom_plan() only choosing
> a generic plan if the average cost of the generic plan is less than
> the average custom plan cost.
On 19 December 2017 at 21:54, Beena Emerson wrote:
> PFA the updated patch.
Hi Beena,
Thanks for updating the patch. I've merged a chunk of your latest
patch with what I was working on and cleaned up some mistakes that I
had made in my WIP version.
I've now done the work to make this work with
Hello,
On Mon, Dec 18, 2017 at 4:03 PM, David Rowley
wrote:
>
>> We could do something similar here using a similar code structure. Maybe,
>> add a ExecSetupPartitionRuntimePruning() in execPartition.c (mimicking
>> ExecSetupPartitionTupleRouting), that accepts AppendState node.
>> Furthermore,
Hi David,
Thank you for reviewing and looking at this.
I have attached the WIP patch which incorporates some of Robert's
comments and is rebased over Amit's v14 patch.
On Sat, Dec 16, 2017 at 11:35 AM, David Rowley
wrote:
> On 13 December 2017 at 00:33, Beena Emerson wrote:
>> PFA the updated
On 18 December 2017 at 21:31, Amit Langote
wrote:
> On 2017/12/16 15:05, David Rowley wrote:
>> I've been looking over this and I think that the use of the
>> PartitionDispatch in set_append_subplan_indexes is not correct. What
>> we need here is the index of the Append's subnode and that's not wh
On 2017/12/09 0:57, Robert Haas wrote:
> On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote:
>> I have added the partition quals that are used for pruning.
>>
>> PFA the updated patch. I have changed the names of variables to make
>> it more appropriate, along with adding more code comments and d
Hi.
On 2017/12/16 15:05, David Rowley wrote:
> On 13 December 2017 at 00:33, Beena Emerson wrote:
>> PFA the updated patch, this can be applied over the v13 patches [1]
>> over commit 487a0c1518af2f3ae2d05b7fd23d636d687f28f3
>
> Hi Beena,
>
> Thanks for posting an updated patch.
>
> I've been
On 13 December 2017 at 00:33, Beena Emerson wrote:
> PFA the updated patch, this can be applied over the v13 patches [1]
> over commit 487a0c1518af2f3ae2d05b7fd23d636d687f28f3
Hi Beena,
Thanks for posting an updated patch.
I've been looking over this and I think that the use of the
PartitionDis
Hello Jesper,
On Tue, Dec 12, 2017 at 4:04 PM, Jesper Pedersen
wrote:
> Hi Beena,
>
> On 12/07/2017 02:22 AM, Beena Emerson wrote:
>>
>> I have added the partition quals that are used for pruning.
>>
>> PFA the updated patch. I have changed the names of variables to make
>> it more appropriate, a
Hello,
On Fri, Dec 8, 2017 at 3:37 AM, David Rowley
wrote:
> On 7 December 2017 at 23:56, Beena Emerson wrote:
>> Currently Amit's v13 patches do not apply on the HEAD and I was
>> working on 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 which is the last
>> commit where all Amit's v13 patches applie
On Tue, Dec 12, 2017 at 4:57 PM, Beena Emerson wrote:
> Hello Robert,
> Thank you for the comments. I have started working on it.
>
> On Fri, Dec 8, 2017 at 9:27 PM, Robert Haas wrote:
>> On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson
>> wrote:
>>> I have added the partition quals that are used
Hello Robert,
Thank you for the comments. I have started working on it.
On Fri, Dec 8, 2017 at 9:27 PM, Robert Haas wrote:
> On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote:
>> I have added the partition quals that are used for pruning.
>>
>> PFA the updated patch. I have changed the names o
Hi Beena,
On 12/07/2017 02:22 AM, Beena Emerson wrote:
I have added the partition quals that are used for pruning.
PFA the updated patch. I have changed the names of variables to make
it more appropriate, along with adding more code comments and doing
some refactoring and other code cleanups.
On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson wrote:
> I have added the partition quals that are used for pruning.
>
> PFA the updated patch. I have changed the names of variables to make
> it more appropriate, along with adding more code comments and doing
> some refactoring and other code cleanu
On 7 December 2017 at 23:56, Beena Emerson wrote:
> Currently Amit's v13 patches do not apply on the HEAD and I was
> working on 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 which is the last
> commit where all Amit's v13 patches applies cleanly.
Thanks.
I was just looking over this and was wonderin
Hello,
On Thu, Dec 7, 2017 at 12:52 PM, Beena Emerson wrote:
>
> 1. Only runtime pruning - David's case1
> explain analyse execute ab_q1 (2,3);
>QUERY PLAN
> ---
Hello David,
On Thu, Dec 7, 2017 at 4:07 PM, David Rowley
wrote:
> On 7 December 2017 at 20:22, Beena Emerson wrote:
>> PFA the updated patch.
>
> Hi Beena,
>
> Thanks for updating this.
>
> Can you list the patches which are required for this to apply to
> today's master branch?
>
Thanks for l
On 7 December 2017 at 20:22, Beena Emerson wrote:
> PFA the updated patch.
Hi Beena,
Thanks for updating this.
Can you list the patches which are required for this to apply to
today's master branch?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On Wed, Dec 6, 2017 at 1:21 PM, David Rowley
wrote:
> On 2 December 2017 at 08:04, Robert Haas wrote:
>> On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson
>> wrote:
>>> David Q1:
>>> postgres=# explain analyse execute ab_q1 (3,3); --const
>>>QUERY PL
On 2 December 2017 at 08:04, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson wrote:
>> David Q1:
>> postgres=# explain analyse execute ab_q1 (3,3); --const
>>QUERY PLAN
>> -
On Sat, Dec 2, 2017 at 3:33 AM, Beena Emerson wrote:
> Append (cost=0.00..395.10 rows=9 width=8) (actual time=0.119..0.119
> rows=0 loops=1) (run-time partition pruning: on)
If we can, it would be better to show something a bit more precise,
like the table being used for run-time pruning, or th
Hello Robert,
On Sat, Dec 2, 2017 at 12:34 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson wrote:
>> David Q1:
>> postgres=# explain analyse execute ab_q1 (3,3); --const
>>QUERY PLAN
>> --
On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson wrote:
> David Q1:
> postgres=# explain analyse execute ab_q1 (3,3); --const
>QUERY PLAN
> -
> App
Hello,
PFA the updated patch rebased over Amit's v13 patches [1] part of
which is committed. This also fixes few bugs I found.
The InitPlans require execPlan which is not set during ExecInitAppend
and so the evaluation of extern quals is moved from ExecInitAppend to
ExecAppend. This changes the ou
Hello,
On Wed, Nov 29, 2017 at 7:11 AM, Michael Paquier
wrote:
> On Wed, Nov 15, 2017 at 3:53 PM, Beena Emerson
> wrote:
>> Thank you for your suggestion. I am looking into this and will post a
>> patch soon.
>
> It has been two weeks since this update and no new patch has showed
> up. I am mar
Hello,
On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
wrote:
> On 15 November 2017 at 01:57, David Rowley
> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath in the Append node so you
>> can correctly identify the subpat
On Tue, Nov 14, 2017 at 6:27 PM, David Rowley
wrote:
> On 14 November 2017 at 19:16, Beena Emerson wrote:
>> PFA the updated patches.
>
> Hi Beena,
>
> Thanks for working on this. I've had a look at the patch to try to
> understand how it is working. I found it a bit surprising that the
> code as
Hello,
PFA the new version of the patch which can be applied over v11 patches
of Amit Langote [1]. The patch has been completely modified and the
0001 patch of previous series is no longer required. As mentioned
above, I have used the PartitionDispatchInfo and an array to which
holds the actual su
Hello Rajkumar,
On Tue, Nov 14, 2017 at 2:22 PM, Rajkumar Raghuwanshi
wrote:
> On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
> wrote:
>>
>> PFA the updated patches.
>
>
> Hi,
>
> I have started testing this along with fast pruning. It is crashing for sql
> with subqueries.
> one to test case
On Wed, Nov 15, 2017 at 3:53 PM, Beena Emerson wrote:
> Thank you for your suggestion. I am looking into this and will post a
> patch soon.
It has been two weeks since this update and no new patch has showed
up. I am marking the patch as returned with feedback. If you can
produce a new version, o
On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
wrote:
> On 15 November 2017 at 01:57, David Rowley
> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath in the Append node so you
>> can correctly identify the subpath based
Hello David,
Thank you for reviewing.
On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
wrote:
> On 15 November 2017 at 01:57, David Rowley
> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath in the Append node so you
>> c
Hello Rajkumar,
On Tue, Nov 14, 2017 at 2:22 PM, Rajkumar Raghuwanshi
wrote:
> On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
> wrote:
>>
>> PFA the updated patches.
>
>
> Hi,
>
> I have started testing this along with fast pruning. It is crashing for sql
> with subqueries.
> one to test case i
On 2017/11/15 8:13, David Rowley wrote:
> So some sort of hierarchical structure of the partition hierarchy
> would need to be stored in the Append node and then you'd need to
> search at each level, and then somehow match the results up to the
> subpaths that you have in the Append. Although, I'm
On 15 November 2017 at 01:57, David Rowley wrote:
> I think to do this you're going to have to store some sort of array
> that maps the partition index to the subpath in the Append node so you
> can correctly identify the subpath based on what you're getting back
> from get_partitions_for_keys().
On 14 November 2017 at 19:16, Beena Emerson wrote:
> PFA the updated patches.
Hi Beena,
Thanks for working on this. I've had a look at the patch to try to
understand how it is working. I found it a bit surprising that the
code assumes it can rely on the order of Append->appendplans matching
what
On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
wrote:
> PFA the updated patches.
>
Hi,
I have started testing this along with fast pruning. It is crashing for sql
with subqueries.
one to test case is given below.
CREATE TABLE prun_test_part (empno int, sal int, deptno int) PARTITION BY
RANGE(
PFA the updated patches.
On Tue, Nov 14, 2017 at 11:45 AM, Beena Emerson wrote:
> Hello Amul,
>
> Thank you for reviewing.
>
> On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote:
>> On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson
>> wrote:
>>> Hello all,
>>>
>>> Here is the updated patch which is r
Hello Amul,
Thank you for reviewing.
On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote:
> On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote:
>> Hello all,
>>
>> Here is the updated patch which is rebased over v10 of Amit Langote's
>> path towards faster pruning patch [1]. It modifies the PartSc
101 - 170 of 170 matches
Mail list logo
