Thanks Tom.
I performed testing with the latest commit and test are
running fine.
On Tue, Jun 28, 2016 at 8:14 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > SELECT setval('s', max(100)) from tab;
> > ERROR: ORDER/GROUP BY expression not found in targetlist
>
> Fixed, thanks for the report!
Rushabh Lathia writes:
> SELECT setval('s', max(100)) from tab;
> ERROR: ORDER/GROUP BY expression not found in targetlist
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Tue, Jun 28, 2016 at 2:52 PM, Rushabh Lathia
wrote:
> Hi,
>
> Consider the below testcase:
>
> CREATE TABLE tab(
> c1 INT NOT NULL,
> c2 INT NOT NULL
> );
> INSERT INTO tab VALUES (1, 2);
> INSERT INTO tab VALUES (2, 1);
> INSERT INTO tab VALUES (1, 2);
>
>
> case 1:
>
> SELECT c.c1, c.c2 f
On Mon, Jun 13, 2016 at 05:27:13PM -0400, Robert Haas wrote:
> One problem that I've realized that is related to this is that the way
> that the consider_parallel flag is being set for upper rels is almost
> totally bogus, which I believe accounts for your complaint at PGCon
> that force_parallel_m
On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > In practice, we don't yet have the ability for
> > parallel-safe paths from subqueries to affect planning at higher query
> > levels, but that's because the pathification stuff landed too late in
> > the cycle for
On Mon, Jun 13, 2016 at 03:42:49PM -0400, Tom Lane wrote:
> I wrote:
> > ... there was also an unexplainable plan change:
>
> > *** /home/postgres/pgsql/src/test/regress/expected/aggregates.out Thu Apr
> > 7 21:13:14 2016
> > --- /home/postgres/pgsql/src/test/regress/results/aggregates.out
Hi,
I ran tpc-h's queries on this version and it's successful.
The error is fixed.
commit 705ad7f3b523acae0ddfdebd270b7048b2bb8029
Author: Tom Lane
Date: Sun Jun 19 13:11:40 2016 -0400
Regards,
Tatsuro Yamada
NTT OSS Center
On 2016/06/18 1:26, Robert Haas wrote:
On Fri, Jun 17, 2016 at 9:
On Fri, Jun 17, 2016 at 9:29 AM, Robert Haas wrote:
> On Fri, Jun 17, 2016 at 9:04 AM, Amit Kapila wrote:
>> Attached, please find updated patch based on above lines. Due to addition
>> of projection path on top of partial paths, some small additional cost is
>> added for parallel paths. In one
On Fri, Jun 17, 2016 at 9:04 AM, Amit Kapila wrote:
> Attached, please find updated patch based on above lines. Due to addition
> of projection path on top of partial paths, some small additional cost is
> added for parallel paths. In one of the tests in select_parallel.sql the
> plan was getting
On Fri, Jun 17, 2016 at 8:18 AM, Amit Kapila
wrote:
>
> On Fri, Jun 17, 2016 at 3:20 AM, Robert Haas
wrote:
> >
>
> > Something like what you have there might work if you use
> > create_projection_path instead of apply_projection_to_path.
> >
>
> Okay, I think you mean to say use create_projectio
På fredag 17. juni 2016 kl. 08:14:39, skrev Amit Kapila mailto:amit.kapil...@gmail.com>>:
On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 16. juni 2016 kl. 20:19:44,
skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
Amit Kapila mailto:amit.kap...@ente
On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh
wrote:
> På torsdag 16. juni 2016 kl. 20:19:44, skrev Tom Lane :
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
> >> min_parallel_relation_size, or min_parallelizable_relation_size, or
> >> something like that
På torsdag 16. juni 2016 kl. 20:19:44, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>> min_parallel_relation_size, or min_parallelizable_relation_size, or
>> something like that?
> You are right that such a variable will
On Fri, Jun 17, 2016 at 3:20 AM, Robert Haas wrote:
>
> On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas
wrote:
> > On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila
wrote:
> >>> 1. The case originally reported by Thomas Munro still fails. To fix
> >>> that, we probably need to apply scanjoin_target to
Amit Kapila writes:
> On Thu, Jun 16, 2016 at 11:49 PM, Tom Lane wrote:
>> But you need to include to use INT_MAX ...
> I wonder why it has not given me any compilation error/warning. I have
> tried it on both Windows and CentOS, before sending the patch.
Some platforms seem to make it availa
On Thu, Jun 16, 2016 at 11:49 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
> >> min_parallel_relation_size, or min_parallelizable_relation_size, or
> >> something like that?
>
> > You are right that such a variable will make it simpler to writ
On Thu, Jun 16, 2016 at 12:16 PM, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila wrote:
>>> 1. The case originally reported by Thomas Munro still fails. To fix
>>> that, we probably need to apply scanjoin_target to each partial path.
>>> But we can only do that if it's paralle
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>> min_parallel_relation_size, or min_parallelizable_relation_size, or
>> something like that?
> You are right that such a variable will make it simpler to write tests for
> parallel query. I have implemented such a guc and
On Thu, Jun 16, 2016 at 12:50 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>>> 3. In https://www.postgresql.org/message-id/25521.1465837...@sss.pgh.pa.us
>>> Tom proposed adding a GUC to set the minimum relation size required
>>> for considerat
Amit Kapila writes:
> On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>> 3. In https://www.postgresql.org/message-id/25521.1465837...@sss.pgh.pa.us
>> Tom proposed adding a GUC to set the minimum relation size required
>> for consideration of parallelism.
> I have posted a patch for this upt
On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila wrote:
>> 1. The case originally reported by Thomas Munro still fails. To fix
>> that, we probably need to apply scanjoin_target to each partial path.
>> But we can only do that if it's parallel-safe. It seems like what we
>> want is something like th
On Thu, Jun 16, 2016 at 9:26 AM, Robert Haas wrote:
>
> On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane wrote:
> > Amit Kapila writes:
> >> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
> >>> ... I got a core dump in the window.sql test:
> >>> which I think may be another manifestation of the
fa
On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
>>> ... I got a core dump in the window.sql test:
>>> which I think may be another manifestation of the failure-to-apply-proper-
>>> pathtarget issue we're looking at in t
On Tue, Jun 14, 2016 at 4:48 PM, Amit Kapila
wrote:
> On Mon, Jun 13, 2016 at 8:11 PM, Tom Lane wrote:
>
> > I do
> > not share your confidence that using apply_projection_to_path within
> > create_grouping_paths is free of such a hazard.
> >
>
> Fair enough, let me try to explain the problem a
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
>> ... I got a core dump in the window.sql test:
>> which I think may be another manifestation of the failure-to-apply-proper-
>> pathtarget issue we're looking at in this thread. Or maybe it's just
>> an unjustified assumpt
Robert Haas writes:
> On Mon, Jun 13, 2016 at 6:21 PM, Tom Lane wrote:
>> I think this is bad because it forces any external creators of
>> UPPERREL_GROUP_AGG to duplicate that code --- and heaven help everybody
>> if anyone is out of sync on whether to set the flag. So I'd rather keep
>> set_gr
On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane wrote:
> >> BTW, decent regression tests could be written without the need to
create
> >> enormous tables if the minimum rel size in create_plain_partial_paths()
> >> could be
David Rowley writes:
> Do you think it's worth also applying the attached so as to have
> ressortgroupref set to NULL more consistently, instead of sometimes
> NULL and other times allocated to memory wastefully filled with zeros?
Meh --- that seems to add complication without buying a whole lot.
On Tue, Jun 14, 2016 at 2:16 AM, Tom Lane wrote:
>
> Robert Haas writes:
> > In practice, we don't yet have the ability for
> > parallel-safe paths from subqueries to affect planning at higher query
> > levels, but that's because the pathification stuff landed too late in
> > the cycle for me to
On Mon, Jun 13, 2016 at 8:11 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 7:51 PM, Tom Lane wrote:
> >> I think the real question here is why the code removed by 04ae11f62
> >> was wrong. It was unsafe to use apply_projection_to_path, certainly,
> >> but using create_
On 14 June 2016 at 04:07, Tom Lane wrote:
> Just as an experiment to see what would happen, I did
>
> - int parallel_threshold = 1000;
> + int parallel_threshold = 1;
>
> and ran the regression tests. I got a core dump in the win
On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
>
> I wrote:
> > Amit Kapila writes:
> >> It is slightly tricky to write a reproducible parallel-query test, but
> >> point taken and I think we should try to have a test unless such a
test is
> >> really time consuming.
>
> > BTW, decent regressio
On Mon, Jun 13, 2016 at 6:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> Again, please have a look at the patch and see if it seems unsuitable
>> to you for some reason. I'm not confident of my ability to get all of
>> this path stuff right without a bit of help from the guy who designed
>> it.
Robert Haas writes:
> Again, please have a look at the patch and see if it seems unsuitable
> to you for some reason. I'm not confident of my ability to get all of
> this path stuff right without a bit of help from the guy who designed
> it.
I'm kind of in a bind right now because Tomas has prod
On Mon, Jun 13, 2016 at 5:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> One problem that I've realized that is related to this is that the way
>> that the consider_parallel flag is being set for upper rels is almost
>> totally bogus, which I believe accounts for your complaint at PGCon
>> that
Robert Haas writes:
> Oh, one other thing about this: I'm not going to try to defend
> whatever confusion between subplans and subqueries appears in that
> comment, but prior to upper planner pathification I think we were dead
> in the water here anyway, because the subquery was going to output a
Robert Haas writes:
> One problem that I've realized that is related to this is that the way
> that the consider_parallel flag is being set for upper rels is almost
> totally bogus, which I believe accounts for your complaint at PGCon
> that force_parallel_mode was not doing as much as it ought to
On Mon, Jun 13, 2016 at 5:27 PM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 4:46 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> In practice, we don't yet have the ability for
>>> parallel-safe paths from subqueries to affect planning at higher query
>>> levels, but that's because the pathifica
On Mon, Jun 13, 2016 at 4:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> In practice, we don't yet have the ability for
>> parallel-safe paths from subqueries to affect planning at higher query
>> levels, but that's because the pathification stuff landed too late in
>> the cycle for me to fully
Robert Haas writes:
> In practice, we don't yet have the ability for
> parallel-safe paths from subqueries to affect planning at higher query
> levels, but that's because the pathification stuff landed too late in
> the cycle for me to fully react to it.
I wonder if that's not just from confusion
On Mon, Jun 13, 2016 at 3:42 PM, Tom Lane wrote:
>> I would not be surprised at a change to a parallel-query plan, but there's
>> no parallelism here, so what happened? This looks like a bug to me.
>> (Also, doing this query without COSTS OFF shows that the newly selected
>> plan actually has a g
I wrote:
> ... there was also an unexplainable plan change:
> *** /home/postgres/pgsql/src/test/regress/expected/aggregates.out Thu Apr
> 7 21:13:14 2016
> --- /home/postgres/pgsql/src/test/regress/results/aggregates.out Mon Jun
> 13 11:54:01 2016
> ***
> *** 577,590
On Mon, Jun 13, 2016 at 1:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane wrote:
>>> BTW, decent regression tests could be written without the need to create
>>> enormous tables if the minimum rel size in create_plain_partial_paths()
>>> could be config
On Mon, Jun 13, 2016 at 7:51 PM, Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Jun 13, 2016 at 3:18 AM, Amit Kapila
wrote:
> >> In create_grouping_paths(), we are building partial_grouping_path and
same
> >> is used for gather path and other grouping paths (for partial paths).
> >> However
On Mon, Jun 13, 2016 at 7:17 PM, Robert Haas wrote:
>
> On Mon, Jun 13, 2016 at 3:18 AM, Amit Kapila
wrote:
> > In create_grouping_paths(), we are building partial_grouping_path and
same
> > is used for gather path and other grouping paths (for partial paths).
> > However, we don't use it for par
Robert Haas writes:
> On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane wrote:
>> BTW, decent regression tests could be written without the need to create
>> enormous tables if the minimum rel size in create_plain_partial_paths()
>> could be configured to something less than 1000 blocks. I think it's
>
On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane wrote:
> Amit Kapila writes:
>> It is slightly tricky to write a reproducible parallel-query test, but
>> point taken and I think we should try to have a test unless such a test is
>> really time consuming.
>
> BTW, decent regression tests could be writt
I wrote:
> Amit Kapila writes:
>> It is slightly tricky to write a reproducible parallel-query test, but
>> point taken and I think we should try to have a test unless such a test is
>> really time consuming.
> BTW, decent regression tests could be written without the need to create
> enormous ta
Amit Kapila writes:
> It is slightly tricky to write a reproducible parallel-query test, but
> point taken and I think we should try to have a test unless such a test is
> really time consuming.
BTW, decent regression tests could be written without the need to create
enormous tables if the minimu
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 7:51 PM, Tom Lane wrote:
>> I think the real question here is why the code removed by 04ae11f62
>> was wrong. It was unsafe to use apply_projection_to_path, certainly,
>> but using create_projection_path directly would have avoided the
>> stated prob
Robert Haas writes:
> On Mon, Jun 13, 2016 at 3:18 AM, Amit Kapila wrote:
>> In create_grouping_paths(), we are building partial_grouping_path and same
>> is used for gather path and other grouping paths (for partial paths).
>> However, we don't use it for partial path list and sort path due to w
On Mon, Jun 13, 2016 at 3:18 AM, Amit Kapila wrote:
> In create_grouping_paths(), we are building partial_grouping_path and same
> is used for gather path and other grouping paths (for partial paths).
> However, we don't use it for partial path list and sort path due to which
> path target for Sor
Hi,
I applied your patch and run tpc-h.
Then I got new errors on Q4,12,17 and 19.
ERROR: Aggref found in non-Agg plan node.
See bellow,
--
postgres=# \i queries/4.explain.sql
ERROR: Aggref found in non-Agg plan node
STATEMENT: explain analyze select
On 2016/06/13 15:52, Michael Paquier wrote:
On Mon, Jun 13, 2016 at 2:42 PM, Tatsuro Yamada
wrote:
I got mistake to write an e-mail to -hackers on last week. :-<
I should have written this.
The bug has not fixed by Tom Lane's patch: commit aeb9ae6.
Because I got the same error using tpc-
On Mon, Jun 13, 2016 at 11:05 AM, David Rowley
wrote:
>
> On 13 June 2016 at 15:39, Thomas Munro
wrote:
> > What is going on here?
>
> ...
>
> >
> > postgres=# set max_parallel_workers_per_gather = 2;
> > SET
> > postgres=# explain select length(data) from logs group by length(data);
> > ERROR:
On Mon, Jun 13, 2016 at 2:42 PM, Tatsuro Yamada
wrote:
> I got mistake to write an e-mail to -hackers on last week. :-<
> I should have written this.
>
> The bug has not fixed by Tom Lane's patch: commit aeb9ae6.
> Because I got the same error using tpc-h.
This looks like a different regressi
Hi,
Subject: Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist
Date: Thu, 09 Jun 2016 12:08:01 +0900
Right, I saw that thread which involved the same error message:
https://www.postgresql.org/message-id/flat/20160526021235.w4nq7k3gnheg7vit%40alap3.anarazel.de#20160526021235.w4nq
On 13 June 2016 at 15:39, Thomas Munro wrote:
> What is going on here?
...
>
> postgres=# set max_parallel_workers_per_gather = 2;
> SET
> postgres=# explain select length(data) from logs group by length(data);
> ERROR: ORDER/GROUP BY expression not found in targetlist
Seems like this was caus
On Mon, Jun 13, 2016 at 4:16 PM, Tatsuro Yamada
wrote:
> I tried to run tpc-h queries, but some queries failed by the error on last
> week.
>
>>Subject: Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist
>>Date: Thu, 09 Jun 2016 12:08:01 +0900
Right, I saw that thread which involved
Hi,
I tried to run tpc-h queries, but some queries failed by the error on last week.
>Subject: Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist
>Date: Thu, 09 Jun 2016 12:08:01 +0900
Today, I try it again by changing max_parallel_workers_per_gather parameter.
The result of Q1 is
60 matches
Mail list logo