On Tue, Oct 25, 2022 at 11:46 AM Japin Li wrote:
>
> On Tue, 25 Oct 2022 at 11:07, Zhihong Yu wrote:
> > Please take a look at patch v2.
>
> Maybe we should define those functions in headers. See patch v3.
Yes, putting them in .h file is better to me. For the v3 patch, we can
do the same
On Tue, Oct 25, 2022 at 10:05 AM John Naylor
wrote:
>
> On Tue, Oct 25, 2022 at 12:19 AM Zhihong Yu wrote:
> >
> > Hi,
> > When I was looking at src/backend/optimizer/util/restrictinfo.c, I found
> a typo in one of the comments.
>
> Using "t" as an abbreviation for "true" was probably
On Mon, Oct 24, 2022 at 6:59 PM Alvaro Herrera
wrote:
> On 2022-Oct-19, Richard Guo wrote:
>
> > Hi hackers,
> >
> > I happened to notice $subject. Attach a trivial patch for that.
>
> Thanks, applied. I did change the comment atop setTargetTable, which I
> th
On Mon, Oct 24, 2022 at 6:01 PM Alvaro Herrera
wrote:
> On 2022-Oct-24, Richard Guo wrote:
> > ISTM the savepointLevel always remains the same as what is in
> > TopTransactionStateData after looking at the codes. Now I also get
> > confused. Maybe what we want is nesti
On Mon, Oct 24, 2022 at 3:00 PM Japin Li wrote:
> On Mon, 24 Oct 2022 at 12:19, Japin Li wrote:
> > The TransactionStateData has savepointLevel field, however, I do not
> understand
> > what is savepoint level, it seems all savepoints have the same
> savepointLevel,
> > I want to know how the
On Fri, Oct 21, 2022 at 3:10 PM Kyotaro Horiguchi
wrote:
> It seems to me that the comment is true and the condition is a thinko.
Yeah, the two conditions could be both false. How about we update the
comment a bit to emphasize this? Such as
/* At most one of these conditions can be true
Hi hackers,
I happened to notice $subject. Attach a trivial patch for that.
Thanks
Richard
v1-0001-Some-comments-that-should-ve-covered-MERGE.patch
Description: Binary data
On Tue, Oct 18, 2022 at 9:15 AM Andy Fan wrote:
> On Mon, Oct 10, 2022 at 10:35 AM Richard Guo
> wrote:
>
>> ... I'm asking because
>> PHVs may imply lateral dependencies which may make us have to use
>> nestloop join.
>>
>
> I thought lateral join imply
On Tue, Oct 18, 2022 at 5:37 AM Tom Lane wrote:
> I came across a couple of places in the planner that are checking
> for nonempty havingQual; but since these bits run after
> const-simplification of the HAVING clause, that produces the wrong
> answer for a constant-true HAVING clause (which'll
On Mon, Oct 17, 2022 at 4:24 PM Alvaro Herrera
wrote:
> While messing about with Cluster.pm I noticed that we don't need the
> hack to work around lack of parent.pm in very old Perl versions, because
> we no longer support those versions (per commit 4c1532763a00). Trivial
> patch attached.
On Mon, Oct 10, 2022 at 10:35 AM Richard Guo wrote:
> As we know when we pull up a simple subquery, if the subquery is within
> the nullable side of an outer join, lateral references to non-nullable
> items may have to be turned into PlaceHolderVars. I happened to wonder
> what
On Fri, Oct 14, 2022 at 10:43 PM Tom Lane wrote:
> Richard Guo writes:
> > Or maybe we can make it even earlier, when we expand an RTE for a
> > partitioned table and add result tables to leaf_result_relids.
>
> I'm not really on board with injecting comman
On Fri, Oct 14, 2022 at 7:19 PM Richard Guo wrote:
>
> On Fri, Oct 14, 2022 at 5:24 PM Alvaro Herrera
> wrote:
>
>> Actually, I hadn't realized that the originally submitted patch had the
>> test in postgres_fdw only, but we really want it to catch any FDW, so it
>&
On Fri, Oct 14, 2022 at 5:24 PM Alvaro Herrera
wrote:
> Actually, I hadn't realized that the originally submitted patch had the
> test in postgres_fdw only, but we really want it to catch any FDW, so it
> needs to be somewhere more general. The best place I found to put this
> test is in
On Fri, Oct 14, 2022 at 12:07 PM Richard Guo wrote:
>
> On Fri, Oct 14, 2022 at 10:59 AM bt22nakamorit <
> bt22nakamo...@oss.nttdata.com> wrote:
>
>> Hi,
>>
>> MERGE command does not accept foreign tables as targets.
>> When a foreign table is spec
On Fri, Oct 14, 2022 at 10:59 AM bt22nakamorit <
bt22nakamo...@oss.nttdata.com> wrote:
> Hi,
>
> MERGE command does not accept foreign tables as targets.
> When a foreign table is specified as a target, it shows error messages
> like this:
>
> -- ERROR: cannot execute MERGE on relation "child1"
On Thu, Oct 13, 2022 at 6:43 PM David Rowley wrote:
> On Thu, 13 Oct 2022 at 21:17, Richard Guo wrote:
> >
> > On Thu, Oct 13, 2022 at 2:48 PM David Rowley
> wrote:
> >> To stop the planner from adding that final sort, I opted to hack the
> >> LimitPath
On Thu, Oct 13, 2022 at 2:48 PM David Rowley wrote:
> On Thu, 13 Oct 2022 at 16:47, Richard Guo wrote:
> > Currently in the patch the optimization is done before we check for
> > presorted paths or do the explicit sort of the cheapest path. How about
> > we m
On Thu, Oct 13, 2022 at 4:50 AM David Rowley wrote:
> The problem is that I'm only added the LimitPath to the
> cheapest_total_path. I think to make your case work we'd need to add
> the LimitPath only in cases where the distinct_pathkeys are empty but
> the sort_pathkeys are not and
On Thu, Oct 13, 2022 at 4:41 AM David Rowley wrote:
> We could do something like set some bool flag in PlannerInfo to tell
> the planner not to bother adding the final LimitPath as we've already
> added another which does the job, but is it really worth adding that
> complexity for this patch?
On Wed, Oct 12, 2022 at 5:19 PM David Rowley wrote:
> When all the distinct pathkeys are redundant then there can only be,
> at most, 1 single distinct value. There may be many rows with that
> value, but we can remove those extra ones with a LIMIT 1 rather than
> troubling over needlessly
On Wed, Oct 12, 2022 at 5:19 PM David Rowley wrote:
> When all the distinct pathkeys are redundant then there can only be,
> at most, 1 single distinct value. There may be many rows with that
> value, but we can remove those extra ones with a LIMIT 1 rather than
> troubling over needlessly
On Wed, Oct 12, 2022 at 12:24 AM Alvaro Herrera
wrote:
> Knowing how difficult that code was, and how heroic was to change it to
> a more maintainable form, I place no blame on failing to notice that
> some small thing could have been written more easily.
Concur with that. The changes in
On Tue, Oct 11, 2022 at 7:05 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Oct 11, 2022 at 3:19 PM Richard Guo
> wrote:
> > On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi <
> horikyota@gmail.com> wrote:
> >> At Mon,
On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi
wrote:
> At Mon, 10 Oct 2022 08:53:55 +0530, Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.com> wrote in
> > It looks like we have an unnecessary XLogSegNoOffsetToRecPtr() in
> > XLogReaderValidatePageHeader(). We pass the start LSN of
Hi hackers,
As we know when we pull up a simple subquery, if the subquery is within
the nullable side of an outer join, lateral references to non-nullable
items may have to be turned into PlaceHolderVars. I happened to wonder
what should we do about the PHVs if the outer join is reduced to inner
On Wed, Sep 21, 2022 at 1:40 PM Michael Paquier wrote:
> In short, switching those code paths to use the linear search routines
> looks like a good thing in the long-term, so I would like to apply
> this patch. If you have any comments or objections, please feel
> free.
Yeah, I agree that the
On Fri, Sep 16, 2022 at 5:59 PM Richard Guo wrote:
> I'm not saying this is a bug, but just curious why param 0 cannot be
> displayed as the referenced expression. And I find the reason is that in
> function find_param_referent(), we have the 'in_same_plan_level' flag
> controllin
I have a question about displaying NestLoopParam. In the plan below,
# explain (costs off)
select * from a, lateral (select sum(i) as i from b where exists (select
sum(c.i) from c where c.j = a.j and c.i = b.i) ) ss where a.i = ss.i;
QUERY PLAN
On Tue, Sep 6, 2022 at 12:39 AM Zhang Mingli wrote:
> Macro exec_subplan_get_plan is not used anymore.
> Attach a patch to remove it.
>
How about add it to the CF to not lose track of it?
Thanks
Richard
On Wed, Jul 27, 2022 at 5:10 PM Xing Guo wrote:
> The bounded heap sorting status flag is set twice in sort_bounded_heap()
> and tuplesort_performsort(). This patch helps remove one of them.
>
Revisiting this patch I think maybe it's better to remove the setting of
Tuplesort status from
On Wed, Sep 14, 2022 at 10:46 AM Kyotaro Horiguchi
wrote:
> I found a small typo in a comment in pgbench.c of 15/master.
>
> - * Return the number fo failed transactions.
> + * Return the number of failed transactions.
>
> While at it, I found "* lot fo unnecessary work." in pg13's
>
On Tue, Sep 13, 2022 at 11:35 AM Zhang Mingli wrote:
> Param isSlice was once used to identity targetTypeId for
> transformAssignmentIndirection.
>
> In commit c7aba7c14e, the evaluation was pushed down to
> transformContainerSubscripts.
>
> No need to keep isSlice around
AFAICS, the Vars forced nonnullable by given clause are only used to
check if we can reduce JOIN_LEFT to JOIN_ANTI, and it is checking the
join's own quals there. It seems to me we do not need to pass down
nonnullable_vars by upper quals to the children of a join.
Attached is a patch to remove
Hi hackers,
While wandering around the codes of reducing outer joins, I noticed that
when determining which base rels/Vars are forced nonnullable by given
clause, we don't take SubPlan into consideration. Does anyone happen to
know what is the concern behind that?
IMO, for SubPlans of type
On Tue, Sep 6, 2022 at 1:18 AM Tom Lane wrote:
> Zhang Mingli writes:
> > Macro exec_subplan_get_plan is not used anymore.
> > Attach a patch to remove it.
>
> Hm, I wonder why it's not used anymore. Maybe we no longer need
> that list at all? If we do, should use of the macro be
>
On Fri, Sep 2, 2022 at 7:09 PM Andrey Lepikhov
wrote:
> On 9/1/22 17:24, Richard Guo wrote:
> > On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > Before flattening procedure we just look through the quals
On Fri, Sep 2, 2022 at 2:52 AM Nathan Bossart
wrote:
> I'm hoping to spend a bit more time looking for additional applications of
> the pg_lfind*() suite of functions (and anywhere else where SIMD might be
> useful, really). If you have any ideas in mind, I'm all ears.
+1 for the proposal. I
On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
wrote:
> Before flattening procedure we just look through the quals of subquery,
> pull to the upper level OpExpr's containing variables from the upper
> relation and replace their positions in the quals with true expression.
> Further, the
On Thu, Sep 1, 2022 at 2:18 PM Etsuro Fujita
wrote:
> While working on something else, I noticed that commit 487e9861d added
> a new field to struct Trigger, but failed to update $SUBJECT to match.
> Attached is a small patch for that.
+1. Good catch.
Thanks
Richard
On Wed, Aug 31, 2022 at 6:57 AM Tom Lane wrote:
> I wrote:
> > The upstream recommendation, which seems pretty sane to me, is to
> > simply reject any string exceeding some threshold length as not
> > possibly being a word. Apparently it's common to use thresholds
> > as small as 64 bytes, but
On Mon, Aug 29, 2022 at 2:30 PM Richard Guo wrote:
>
> On Fri, Aug 19, 2022 at 2:45 AM Tom Lane wrote:
>
>> Here's a rebase up to HEAD, mainly to get the cfbot back in sync
>> as to what's the live patch.
>
>
> Noticed another different behavior from previous. Whe
On Fri, Aug 19, 2022 at 2:45 AM Tom Lane wrote:
> Here's a rebase up to HEAD, mainly to get the cfbot back in sync
> as to what's the live patch.
Noticed another different behavior from previous. When we try to reduce
JOIN_LEFT to JOIN_ANTI, we want to know if the join's own quals are
strict
On Thu, Aug 25, 2022 at 5:18 AM Tom Lane wrote:
> Richard Guo writes:
> > Do we need to also
> > generate two SpecialJoinInfos for the B/C join in the first order, with
> > and without the A/B join in its min_lefthand?
>
> No, the SpecialJoinInfos would stay as
On Wed, Aug 24, 2022 at 7:12 PM Richard Guo wrote:
>
> On Wed, Aug 24, 2022 at 6:49 PM Alvaro Herrera
> wrote:
>
>> On 2022-Aug-24, mahendrakar s wrote:
>>
>> > Hi,
>> > Can we have a parameter to control the recursion depth in these cases to
>
On Wed, Aug 24, 2022 at 6:49 PM Alvaro Herrera
wrote:
> On 2022-Aug-24, mahendrakar s wrote:
>
> > Hi,
> > Can we have a parameter to control the recursion depth in these cases to
> > avoid crashes?
>
> We already have one (max_stack_depth). The problem is lack of calling
> the control function
On Sun, Aug 21, 2022 at 6:52 AM Tom Lane wrote:
> What I'm thinking we should do about this, once we detect that
> this identity is applicable, is to generate *both* forms of Pbc,
> either adding or removing the varnullingrels bits depending on
> which form we got from the parser. Then, when we
On Wed, Aug 17, 2022 at 4:57 AM Tom Lane wrote:
> On further thought, it seems better to maintain the index array
> from the start, allowing complete replacement of the linear list
> searches. We can add a separate bool flag to denote frozen-ness.
+1 for 0001 patch. Now we process plain Vars
On Tue, Aug 2, 2022 at 3:51 AM Tom Lane wrote:
> Here's a rebase up to HEAD, mostly to placate the cfbot.
> I accounted for d8e34fa7a (s/all_baserels/all_query_rels/
> in those places) and made one tiny bug-fix change.
> Nothing substantive as yet.
When we add required PlaceHolderVars to a
On Mon, Aug 15, 2022 at 12:17 AM Tomas Vondra
wrote:
> So prefix_size includes the null byte, so the assert points out at the
> first payload byte. And of course, the check should be "==" because we
> expect the byte to be \0, not the other way around.
Yes, indeed. There is even a comment
On Wed, Aug 10, 2022 at 4:40 PM Alvaro Herrera
wrote:
> On 2022-Aug-10, Richard Guo wrote:
>
> > The right-anti join plan has the same cost estimation with right join
> > plan in this case. So would you please help to test what the right join
> > plan looks like in your
On Tue, Aug 9, 2022 at 6:54 PM Alvaro Herrera
wrote:
> I suppose this looks good as far as the plan goes, but the cost estimation
> might be a little bit too optimistic: it is reporting that the new plan
> costs 50% of the original, yet the execution time is only 5% lower.
Thanks for trying
On Tue, Aug 2, 2022 at 3:13 PM Richard Guo wrote:
> On Sun, Jul 31, 2022 at 12:07 AM Tom Lane wrote:
>
>> I took a quick look through this. The executor changes are indeed
>> impressively short, but that's largely because you've paid zero
>> attention to upd
On Thu, Aug 4, 2022 at 4:38 PM Michael Paquier wrote:
> On Tue, Aug 02, 2022 at 07:25:49PM +0900, Michael Paquier wrote:
> > These declarations are linked to comments with their file paths, so
> > making that automated looks rather complicated to me. I have looked
> > at the surroundings
While doing the search in [1], I spotted several places where the
comments for the function prototypes are obsoleted. For instance,
btree_desc() and btree_identify() are now located in nbtdesc.c but the
comment in nbtxlog.h is still claiming they are in nbtxlog.c.
Fix these places with the
On Tue, Aug 2, 2022 at 12:13 PM John Naylor
wrote:
>
> On Tue, Aug 2, 2022 at 10:06 AM Richard Guo
> wrote:
> >
> > I'm not sure that we should remove such comments. And a rough search
> > shows that there are much more places with this kind of comments, such
&g
On Sun, Jul 31, 2022 at 12:07 AM Tom Lane wrote:
> Richard Guo writes:
> > [ v4-0001-Using-each-rel-as-both-outer-and-inner-for-anti-j.patch ]
>
> I took a quick look through this. The executor changes are indeed
> impressively short, but that's largely because you've pai
On Mon, Aug 1, 2022 at 10:42 PM Japin Li wrote:
>
> On Mon, 01 Aug 2022 at 22:16, Tom Lane wrote:
> > John Naylor writes:
> >> You are correct, but I wonder if it'd be better to just drop the comment
> >> entirely. I checked a couple other random headers with function
> >> declarations and
On Mon, Aug 1, 2022 at 5:18 PM Japin Li wrote:
> I think there is a typo in pg_db_role_setting.h, should we fix it?
Definitely this is wrong. +1 for the fix.
Thanks
Richard
On Thu, Jul 28, 2022 at 9:04 PM Zhang Mingli wrote:
> Assertions added.
>
Can we also add assertions to make sure force_quote, force_notnull and
force_null are available only in CSV mode?
Thanks
Richard
On Wed, Jul 27, 2022 at 5:10 PM Xing Guo wrote:
> The bounded heap sorting status flag is set twice in sort_bounded_heap()
> and tuplesort_performsort(). This patch helps remove one of them.
>
+1. Looks good to me.
Thanks
Richard
On Wed, Jul 27, 2022 at 12:55 PM Kyotaro Horiguchi
wrote:
> ProcessCopyOptions previously rejects force_quote_all for COPY FROM
> and copyfrom.c is not even conscious of the option (that is, even no
> assertion on it). The two options are rejected for COPY TO by the same
> function so it seems
On Wed, Jul 27, 2022 at 6:46 AM David Rowley wrote:
> On Tue, 26 Jul 2022 at 19:39, Richard Guo wrote:
> > Also I'm wondering if it's possible to take into consideration the
> > ordering indicated by existing indexes when determining the pathkeys. So
> > that for the que
On Tue, Jul 26, 2022 at 3:44 PM Yugo NAGATA wrote:
> If such two transactions run concurrently, a write skew anomaly occurs,
> and the result of order_summary refreshed in T1 will not contain the
> record inserted in T2.
Indeed we have write skew anomaly here between the two transactions.
>
On Tue, Jul 26, 2022 at 7:38 AM David Rowley wrote:
> On Fri, 22 Jul 2022 at 21:33, Richard Guo wrote:
> > I can see this problem with
> > the query below:
> >
> > select max(b order by b), max(a order by a) from t group by a;
> >
> > When pro
On Mon, Jul 25, 2022 at 2:22 AM Heikki Linnakangas wrote:
> if (BufferIsLocal(recent_buffer))
> {
> - bufHdr = GetBufferDescriptor(-recent_buffer - 1);
> + bufHdr = GetLocalBufferDescriptor(-recent_buffer - 1);
Aha, we're using the wrong buffer
On Fri, Jul 2, 2021 at 11:23 AM Richard Guo wrote:
> Thanks! Test cases are updated in v3 patch. Also merge join can do the
> 'right anti join' too in the same patch.
>
> Thanks again for reviewing this patch.
>
Rebased this patch with latest master, with no other changes.
Than
On Wed, Jul 20, 2022 at 1:27 PM David Rowley wrote:
> I've been working on this patch again. There was a bit of work to do
> to rebase it atop db0d67db2. The problem there was that since this
> patch appends pathkeys to suit ORDER BY / DISTINCT aggregates to the
> query's group_pathkeys,
On Tue, Sep 10, 2019 at 9:49 PM Tom Lane wrote:
> > Can we try to pull up direct-correlated ANY SubLink with the help of
> > LATERAL?
>
> Perhaps. But what's the argument that you'd end up with a better
> plan? LATERAL pretty much constrains things to use a nestloop,
> so I'm not sure there's
On Thu, Jul 21, 2022 at 3:47 AM David Rowley wrote:
> On Wed, 20 Jul 2022 at 21:19, Richard Guo wrote:
> > So the idea is if the ECs used by the mergeclauses are prefix of the
> > query_pathkeys, we use this prefix as pathkeys for the mergejoin. Why
> > not relax this fu
On Wed, Jul 20, 2022 at 11:03 AM David Rowley wrote:
> I think we can relax this now that we have incremental sort. I think
> a better way to limit this is to allow a prefix of the query_pathkeys
> providing that covers *all* of the join pathkeys. That way, for the
> above query, it leaves it
On Tue, Jul 19, 2022 at 1:30 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2022-Jul-18, Richard Guo wrote:
> >> BTW, not related to this patch, the new lines for parallel_aware check
> >> in setrefs.c are very wide. How about wrap them to keep consisten
On Fri, Jul 15, 2022 at 5:00 PM Richard Guo wrote:
> On Fri, Jul 15, 2022 at 4:03 PM Richard Guo
> wrote:
>
>> On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote:
>>
>>> I'd prefer a test that demonstrates that the Gather node at the top of
>>> the
On Mon, Jul 18, 2022 at 3:16 AM Tom Lane wrote:
> I wrote:
> > I also notice that setrefs.c can elide Append and MergeAppend nodes
> > too in some cases, but AFAICS costing of those node types doesn't
> > take that into account.
>
> I took a closer look at this point and realized that in fact,
>
On Fri, Jul 15, 2022 at 4:03 PM Richard Guo wrote:
>
> On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote:
>
>> I'd prefer a test that demonstrates that the Gather node at the top of the
>> "subproblem plan" is useful purely from the *cost* perspective, ra
On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote:
> I'd prefer a test that demonstrates that the Gather node at the top of the
> "subproblem plan" is useful purely from the *cost* perspective, rather than
> due to executor limitation.
This patch provides an additional path (Gather atop of
On Wed, Jul 13, 2022 at 1:31 AM Tom Lane wrote:
> I tried the attached quick-hack patch that just prevents
> remove_useless_groupby_columns from removing anything that
> appears in ORDER BY. That successfully fixes the complained-of
> case, and it doesn't change any existing regression test
On Tue, Jul 12, 2022 at 9:37 PM Tom Lane wrote:
> Richard Guo writes:
> > Note that the evaluation of expression 'b.j + 1' now occurs below the
> > outer join. Is this something we need to be concerned about?
>
> It seems more formally correct to me, but perhaps somebody w
On Mon, Jul 11, 2022 at 3:38 AM Tom Lane wrote:
> Here's v2 of this patch series. It's functionally identical to v1,
> but I've rebased it over the recent auto-node-support-generation
> changes, and also extracted a few separable bits in hopes of making
> the main planner patch smaller. (It's
On Wed, Jul 6, 2022 at 10:48 PM Tom Lane wrote:
> Typically, if one applies outerPlan() or outerPlanState() to the
> wrong pointer, the mistake will become obvious upon even minimal
> testing. My concern here is more about usages in edge cases that
> perhaps escape testing, for instance in the
Thanks for reviewing this patch.
On Sat, Jul 2, 2022 at 5:32 AM Tom Lane wrote:
> Richard Guo writes:
> > In the executor code, we mix use outerPlanState macro and referring to
> > leffttree. Commit 40f42d2a tried to keep the code consistent by
> > replacing
On Sat, Jul 2, 2022 at 12:42 AM Tom Lane wrote:
>
> Anyway, even though this is far from done, I'm pretty pleased with
> the results so far, so I thought I'd put it out for review by
> anyone who cares to take a look. I'll add it to the September CF
> in hopes that it might be more or less
On Wed, Jun 15, 2022 at 11:33 AM XueJing Zhao wrote:
> Recently I work on grouping sets and I find the last param numGroups of
> create_groupingsets_path is not used.
>
> In create_groupingsets_path we use rollup->numGroups to do cost_agg.
>
Yes indeed. The param 'numGroups' was used originally
On Mon, May 9, 2022 at 11:56 PM Tom Lane wrote:
> Example (you need up-to-the-minute HEAD for this particular test
> case, but anything that runs a little while before failing will do):
>
> regression=# \timing
> Timing is on.
> regression=# select * from generate_series('2022-01-01
On Thu, May 5, 2022 at 7:03 AM Tom Lane wrote:
> I wrote:
> > I instrumented the code in setrefs.c, and found that during the
> > core regression tests this patch estimates correctly in 2103
> > places while guessing wrongly in 54, so that seems like a pretty
> > good step forward.
>
> On second
On Fri, Apr 29, 2022 at 12:53 AM Robert Haas wrote:
> Gather doesn't require a parallel aware subpath, just a parallel-safe
> subpath. In a case like this, the parallel seq scan will divide the
> rows from the underlying relation across the three processes executing
> it. Each process will pass
On Mon, Nov 22, 2021 at 3:04 PM Richard Guo wrote:
>
> The suggested changes have already been included in v5 patch. Sorry for
> the confusion.
>
> Verified that the patch still applies and works on latest master. So I'm
> moving it to the next CF (which is Commitfest 2022-0
On Thu, Apr 21, 2022 at 3:51 PM Richard Guo wrote:
>
> On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra <
> tomas.von...@enterprisedb.com> wrote:
>
>>
>> it seems there's something wrong with CTE inlining when there's a view
>> containing a correlated subquery re
On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra
wrote:
>
> it seems there's something wrong with CTE inlining when there's a view
> containing a correlated subquery referencing the CTE.
>
BTW, seems view is not a necessary condition to reproduce this issue.
For instance:
create table t (a int, b
On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra
wrote:
>
> The difference between plans in (2) and (3) is interesting, because it
> seems the CTE got inlined, so why was the refcount not decremented?
>
The query is not actually referencing the cte. So the cte range table
entry would not appear
On Thu, Apr 21, 2022 at 12:02 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 18.04.22 09:35, Richard Guo wrote:
> > The array sortgrouprefs[] inside PathTarget might be NULL if we have not
> > identified sort/group columns in this tlist. In that case we
On Tue, Apr 19, 2022 at 2:53 AM Tom Lane wrote:
>
> A semantics-preserving conversion would have looked something like
>
> if (node->sortgrouprefs)
> WRITE_INDEX_ARRAY(sortgrouprefs, list_length(node->exprs));
>
> I suppose that Peter was trying to remove special cases from the
>
The array sortgrouprefs[] inside PathTarget might be NULL if we have not
identified sort/group columns in this tlist. In that case we would have
a NULL pointer reference in _outPathTarget() when trying to print
sortgrouprefs[] with WRITE_INDEX_ARRAY as we are using the length of
PathTarget->exprs
On Fri, Apr 15, 2022 at 12:50 AM Robert Haas wrote:
> On Tue, Apr 12, 2022 at 2:57 AM bu...@sohu.com wrote:
> > The cost_subqueryscan function does not judge whether it is parallel.
>
> I don't see any reason why it would need to do that. A subquery scan
> isn't parallel aware.
>
> > regress
>
In the executor code, we mix use outerPlanState macro and referring to
leffttree. Commit 40f42d2a tried to keep the code consistent by
replacing referring to lefftree with outerPlanState macro, but there are
still some outliers. This patch tries to clean them up.
Thanks
Richard
On Sat, Apr 9, 2022 at 5:26 AM Alvaro Herrera
wrote:
> On 2022-Apr-06, Richard Guo wrote:
>
> > That's right. The varattno is set to zero for whole-row Var. And in this
> > case these whole-row Vars are not included in the targetlist.
> >
> > Attached is a
On Wed, Apr 6, 2022 at 6:18 AM Joe Wildish wrote:
> Hello Hackers,
>
> Reporting a bug with the new MERGE statement. Tested against
> 75edb919613ee835e7680e40137e494c7856bcf9.
>
> psql output as follows:
>
> ...
> psql:merge.sql:33: ERROR: variable not found in subplan target lists
> ROLLBACK
>
On Fri, Nov 26, 2021 at 5:23 PM Julien Rouhaud wrote:
> Hi,
>
> On Fri, Nov 26, 2021 at 2:10 PM Richard Guo
> wrote:
> >
> > Seems point_inside() does not handle NaN properly.
>
> This is unfortunately a known issue, which was reported twice ([1] and
> [2]) a
Here is how it can be reproduced.
create table point_tbl (f1 point);
insert into point_tbl(f1) values ('(5.1, 34.5)');
insert into point_tbl(f1) values (' ( Nan , NaN ) ');
analyze;
create index gpointind on point_tbl using gist (f1);
set enable_seqscan to on;
set enable_indexscan to off;
#
On Wed, Oct 6, 2021 at 1:19 AM Jaime Casanova
wrote:
> On Wed, Jul 21, 2021 at 04:44:53PM +0800, Richard Guo wrote:
> > On Fri, Nov 27, 2020 at 8:05 PM Ashutosh Bapat <
> ashutosh.bapat@gmail.com>
> > wrote:
> >
> > >
> > > In the example
501 - 600 of 696 matches
Mail list logo
