Hi,
When looking at [1], I realized we may have a side effect when removing
redundant columns in the GROUP BY clause. Suppose we have a query with
ORDER BY 'b', and meanwhile column 'b' is also a group key. If we decide
that 'b' is redundant due to being functionally dependent on other GROUP
BY co
Hi,
On Sun, Feb 28, 2021 at 5:15 PM David Rowley wrote:
> On Sun, 28 Feb 2021 at 20:52, Richard Guo wrote:
> > When looking at [1], I realized we may have a side effect when removing
> > redundant columns in the GROUP BY clause. Suppose we have a query with
> > ORDER
On Fri, Nov 6, 2020 at 11:26 PM Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> Status update for a commitfest entry.
>
> According to CFbot this patch fails to apply. Richard, can you send an
> update, please?
>
> Also, I see that the thread was inactive for a while.
> Are you goin
Happened to notice this when reading around the codes. The BrinMemTuple
would be initialized in brin_new_memtuple(), right after being created.
So we don't need to initialize it again outside.
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index ccc9fa0959..67a277e1f9
On Sat, Nov 20, 2021 at 12:23 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Fri, Nov 19, 2021 at 1:13 PM Richard Guo
> wrote:
> >
> > Happened to notice this when reading around the codes. The BrinMemTuple
> > would be initialized in br
On Mon, Nov 22, 2021 at 12:52 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Nov 22, 2021 at 8:53 AM Richard Guo
> wrote:
> >
> >
> > On Sat, Nov 20, 2021 at 12:23 AM Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.
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 you
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;
# sel
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
Hi Amit,
On Wed, Sep 4, 2019 at 10:01 AM Amit Langote
wrote:
> Fujita-san,
>
> To avoid losing track of this, I've added this to November CF.
>
> https://commitfest.postgresql.org/25/2278/
>
> I know there is one more patch beside the partitionwise join fix, but
> I've set the title to suggest t
Hi Amit,
On Wed, Sep 4, 2019 at 3:30 PM Richard Guo wrote:
> Hi Amit,
>
> On Wed, Sep 4, 2019 at 10:01 AM Amit Langote
> wrote:
>
>> Fujita-san,
>>
>> To avoid losing track of this, I've added this to November CF.
>>
>> https://commitfest.post
Hi,
Currently we do not try to pull up sub-select of type ANY_SUBLINK if it
refers to any Vars of the parent query, as indicated in the code snippet
below:
JoinExpr *
convert_ANY_sublink_to_join(PlannerInfo *root, SubLink *sublink,
Relids available_rels)
{
...
Hi Alvaro,
Thank you for reviewing this patch.
On Wed, Sep 11, 2019 at 4:48 AM Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> wrote:
> So in this patch, the input restrictlist is modified to include the
> clauses generated by generate_join_implied_equalities_for_all. That
> doesn't
Hi Antonin,
On Tue, Sep 10, 2019 at 4:31 PM Antonin Houska wrote:
> Richard Guo wrote:
>
> > Can we try to pull up direct-correlated ANY SubLink with the help of
> > LATERAL?
>
> > By this way, we can convert the query:
> >
> > select * from a where a.
Hi Antonin,
On Wed, Sep 11, 2019 at 3:25 PM Antonin Houska wrote:
>
> Nevertheless, I don't know how to overcome the problems that I mentioned
> upthread.
>
Do you mean the problem "the WHERE clause of the subquery didn't
participate in the SEMI JOIN evaluation"? Good news is it has been fixed
Hi Tom,
On Tue, Sep 10, 2019 at 9:48 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 sur
On Thu, Sep 12, 2019 at 11:35 PM Antonin Houska wrote:
> Richard Guo wrote:
>
> > On Wed, Sep 11, 2019 at 3:25 PM Antonin Houska
> > wrote:
> >
> >
> > Nevertheless, I don't know how to overcome the problems that I
> > mentioned
> &
Hi Dilip,
Thank you for reviewing this patch.
On Fri, Sep 20, 2019 at 12:48 PM Dilip Kumar wrote:
> On Thu, Aug 29, 2019 at 3:15 PM Richard Guo wrote:
> >
> >
> > Attached is a patch as an attempt to address this issue. The idea is
> > quite straightforward. When
On Thu, Sep 19, 2019 at 4:15 PM Amit Langote
wrote:
> Hi Richard,
>
> Thanks a lot for taking a close look at the patch and sorry about the
> delay.
>
> On Wed, Sep 4, 2019 at 5:29 PM Richard Guo wrote:
> >> On Wed, Sep 4, 2019 at 10:01 AM Amit Langote
> wrote:
&
On Tue, Feb 26, 2019 at 6:51 AM Li, Zheng wrote:
> Resend the patch with a whitespace removed so that "git apply patch" works
> directly.
>
>
Hi Zheng,
I have reviewed your patch. Good job except two issues I can find:
1. The patch would give wrong results when the inner side is empty. In this
On Wed, Jun 12, 2019 at 10:58 AM Richard Guo wrote:
> Hi all,
>
> Paul and I have been hacking recently to implement parallel grouping
> sets, and here we have two implementations.
>
> Implementation 1
>
>
> Attached is the patch and also there is a
On Tue, Jul 30, 2019 at 11:05 PM Tomas Vondra
wrote:
> On Tue, Jul 30, 2019 at 03:50:32PM +0800, Richard Guo wrote:
> >On Wed, Jun 12, 2019 at 10:58 AM Richard Guo wrote:
> >
> >> Hi all,
> >>
> >> Paul and I have been hacking recently to implement par
On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
> 2019年8月1日(木) 1:41 Tom Lane :
> >
> > Robert Haas writes:
> > > Yeah, but I have to admit that this whole design makes me kinda
> > > uncomfortable. Every time somebody comes up with a new figure of
> > > merit, it increases not only the numbe
On Thu, Aug 1, 2019 at 5:38 PM Arne Roland wrote:
> Hello,
>
> I attached one example of a partitioned table with multi column partition
> key. I also attached the output.
> Disabling the hash_join is not really necessary, it just shows the more
> drastic result in the case of low work_mem.
>
> C
On Thu, Aug 1, 2019 at 10:15 PM Tom Lane wrote:
> Richard Guo writes:
> > For the third query, a rough investigation shows that, the qual 'sl =
> > 5' and 'sc.sl = sg.sl' will form an equivalence class and generate two
> > implied equalities: 's
On Thu, Aug 1, 2019 at 7:46 PM Arne Roland wrote:
> Hello Richard,
>
> thanks for your quick reply.
>
>
> > We need to fix this.
>
>
> Do you have a better idea than just keeping the old quals - possibly just
> the ones that get eliminated - in a separate data structure? Is the push
> down of qua
On Wed, Aug 21, 2019 at 9:30 AM Alex wrote:
>
> first issue "set default_transaction_isolation to 'serializable';" on the
> both sessions, then run:
>
> Session 1: begin; select * from t; (2 rows selected);
> Session 2: delete from t; (committed automatically)
> Session 1: commit; (com
Hi All,
To generate partitionwise join, we need to make sure there exists an
equi-join condition for each pair of partition keys, which is performed
by have_partkey_equi_join(). This makes sense and works well.
But if, let's say, one certain pair of partition keys (foo.k = bar.k)
has formed an eq
On Tue, Aug 27, 2019 at 8:51 AM Amit Langote
wrote:
> Hi Richard,
>
> On Mon, Aug 26, 2019 at 6:33 PM Richard Guo wrote:
> >
> > Hi All,
> >
> > To generate partitionwise join, we need to make sure there exists an
> > equi-join condition for each pai
On Wed, Aug 28, 2019 at 6:49 PM Etsuro Fujita
wrote:
> Hi,
>
> On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote:
> > Check the query below as a more illustrative example:
> >
> > create table p (k int, val int) partition by range(k);
> > create table p_1 part
On Fri, Aug 30, 2019 at 2:08 AM Etsuro Fujita
wrote:
> On Thu, Aug 29, 2019 at 6:45 PM Richard Guo wrote:
> > On Wed, Aug 28, 2019 at 6:49 PM Etsuro Fujita
> wrote:
> >> On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote:
> >> > Check the query bel
On Fri, Nov 29, 2019 at 11:03 AM Michael Paquier
wrote:
> On Tue, Nov 26, 2019 at 08:35:33PM +0900, Etsuro Fujita wrote:
> > I've just started reviewing this patch. One comment I have for now
> > is: this is categorized into Bug Fixes, but we have a workaround at
> > least to the regression test
On Sun, Dec 1, 2019 at 10:03 AM Michael Paquier wrote:
> On Thu, Nov 28, 2019 at 07:07:22PM +0800, Pengzhou Tang wrote:
> > Richard pointed out that he get incorrect results with the patch I
> > attached, there are bugs somewhere,
> > I fixed them now and attached the newest version, please refer
Rebased the patch with latest master and also addressed the test case
failure reported by PostgreSQL Patch Tester.
Thanks
Richard
On Fri, Nov 29, 2019 at 11:35 AM Etsuro Fujita
wrote:
> On Fri, Nov 29, 2019 at 12:08 PM Richard Guo wrote:
> > On Fri, Nov 29, 2019 at 11:03 AM Michae
a separate thread.
With this idea, here is the patch for 'Implementation 1' that is rebased
with the latest master.
Thanks
Richard
On Wed, Jan 8, 2020 at 3:24 PM Richard Guo wrote:
>
> On Sun, Dec 1, 2019 at 10:03 AM Michael Paquier
> wrote:
>
>> On Thu, Nov 28, 2
Hi,
This is a follow-up to the issue described in thread
https://www.postgresql.org/message-id/CAMbWs4-Mys%3DhBQSevTA8Zpd-TYFnb%3DXuHhN2TnktXMsfMUbjiQ%40mail.gmail.com
In short, during the first transaction starting phase within a backend, if
there is an 'ereport' after setting transaction state
Hi Michael,
Thanks for your input.
On Thu, Oct 11, 2018 at 11:38 AM, Michael Paquier
wrote:
> On Wed, Oct 10, 2018 at 03:37:50PM +0800, Richard Guo wrote:
> > This is a follow-up to the issue described in thread
> > https://www.postgresql.org/message-id/CAMbWs4-Mys%3DhBQ
Hi hackers,
Currently for quals in the form of "NOT NOT (SubLink)", this SubLink would
not
be considered when pulling up sublinks. For instance:
gpadmin=# explain select * from a where NOT NOT (a.i in (select b.i from
b));
QUERY PLAN
--
Hi Alex,
Yes hashed SubPlan preserves order and may be faster than hash join in some
cases. But I don't think that is a reason good enough to prevent the subplan
from being converted to join.
Let's suppose the subplan is uncorrelated, otherwise hashed SubPlan would
not
be used. Hashed SubPlan can
Hi Tom,
Thanks for reviewing.
On Tue, Nov 13, 2018 at 10:05 AM, Tom Lane wrote:
> Richard Guo writes:
> > Currently for quals in the form of "NOT NOT (SubLink)", this SubLink
> would
> > not be considered when pulling up sublinks.
>
> Yup.
>
> > Sh
Hi Tom,
Thanks for your input.
On Fri, Nov 16, 2018 at 6:06 AM, Tom Lane wrote:
> Richard Guo writes:
> > On Tue, Nov 13, 2018 at 10:05 AM, Tom Lane wrote:
> >> What is the argument that this occurs often enough to be worth expending
> >> extra cycles and code spa
Updated this patch over 29f114b6ff, which indicates that we should apply
the same rules for PHVs.
Thanks
Richard
v3-0001-Avoid-unnecessary-PlaceHolderVars-for-Vars-PHVs.patch
Description: Binary data
On Mon, Jan 15, 2024 at 8:20 AM Alexander Korotkov
wrote:
> Thank you for providing the test case relevant for this code change.
> The revised patch incorporating this change is attached. Now the
> patchset looks good to me. I'm going to push it if there are no
> objections.
Seems I'm late fo
On Mon, Jan 15, 2024 at 3:56 PM Alexander Korotkov
wrote:
> On Mon, Jan 15, 2024 at 8:42 AM Richard Guo
> wrote:
> > On Mon, Jan 15, 2024 at 8:20 AM Alexander Korotkov
> wrote:
> >>
> >> Thank you for providing the test case relevant for this code change.
>
On Tue, Jan 16, 2024 at 11:08 AM David Rowley wrote:
> I've now adjusted the patch to have all modifications to Bitmapsets
> return a newly allocated set. There are a few cases missing in master
> that need to be fixed (items 6-10 below):
>
> The patch now includes changes for the following:
>
>
On Tue, Jan 16, 2024 at 11:32 AM David Rowley wrote:
> While working on [1], I noticed some strange code in
> DiscreteKnapsack() which seems to be aiming to copy the Bitmapset.
>
> It's not that obvious at a casual glance, but:
>
> sets[j] = bms_del_members(sets[j], sets[j]);
>
> this is aiming t
On Wed, Jan 17, 2024 at 8:47 AM Yongtao Huang
wrote:
> Hi all,
> I think the comment above the function DecodeInsert()
> in src/backend/replication/logical/decode.c should be
> + * *Inserts *can contain the new tuple.
> , rather than
> - * *Deletes *can contain the new tuple.
>
Nice catch. +1.
On Tue, Jan 16, 2024 at 2:30 AM Robert Haas wrote:
> On Mon, Jan 8, 2024 at 3:32 AM Richard Guo wrote:
> > Thanks for the suggestion. Attached is an updated patch which is added
> > with a commit message that tries to explain the problem and the fix.
>
> This is great. T
On Wed, Jan 17, 2024 at 5:01 PM Richard Guo wrote:
> On Tue, Jan 16, 2024 at 2:30 AM Robert Haas wrote:
>
>> On Mon, Jan 8, 2024 at 3:32 AM Richard Guo
>> wrote:
>
> > Fair point. I think we can back-patch a more minimal fix, as Tom
>> > proposed in [1], wh
On Thu, Jan 18, 2024 at 8:35 AM David Rowley wrote:
> The functions's header comment mentions "The bitmapsets are all
> pre-initialized with an unused high bit so that memory allocation is
> done only once.".
Ah, I neglected to notice this when reviewing the v1 patch. I guess
it's implemented
Similar to what we did to GROUP BY keys in 0452b461bc, I think we can do
the same to DISTINCT keys, i.e. reordering DISTINCT keys to match input
path's pathkeys, which can help reduce cost by avoiding unnecessary
re-sort, or allowing us to use incremental-sort to save efforts. For
instance,
creat
On Tue, Jan 23, 2024 at 1:11 PM David Rowley wrote:
> I went over this again. I did a little more work adjusting comments
> and pushed it.
>
> Thanks for all your assistance with this, Richard.
Thanks for pushing! This is really great.
Thanks
Richard
I came across a warning when building master (a044e61f1b) on old GCC
(4.8.5).
jsonfuncs.c: In function ‘jsonb_populate_record_valid’:
../../../../src/include/nodes/miscnodes.h:53:15: warning: the comparison
will always evaluate as ‘true’ for the address of ‘escontext’ will never be
NULL [-Waddress
On Sun, Jan 21, 2024 at 8:36 PM vignesh C wrote:
> I'm seeing that there has been no activity in this thread for nearly 7
> months, I'm planning to close this in the current commitfest unless
> someone is planning to take it forward.
This patch fixes the wrong comments in try_partial_hashjoin_p
On Thu, Jan 25, 2024 at 2:28 PM Amit Langote
wrote:
> On Thu, Jan 25, 2024 at 2:59 PM Richard Guo
> wrote:
> > I came across a warning when building master (a044e61f1b) on old GCC
> > (4.8.5).
> >
> > jsonfuncs.c: In function ‘jsonb_populate_record_valid’:
>
On Fri, Jan 26, 2024 at 2:32 AM Tom Lane wrote:
> I'm fairly sure I thought it wouldn't matter because of the Param
> de-duplication done in paramassign.c. However, Richard's example
> shows that's not so, because process_subquery_nestloop_params is
> picky about the param ID assigned to a parti
On Fri, Jan 26, 2024 at 1:22 AM Tom Lane wrote:
> Apologies for not having noticed this thread before. I'm taking
> a look at it now. However, while sniffing around this I found
> what seems like an oversight in paramassign.c's
> assign_param_for_var(): it says it should compare all the same
>
On Fri, Jan 26, 2024 at 12:18 PM David Rowley wrote:
> On Fri, 26 Jan 2024 at 16:51, Tom Lane wrote:
> > >> However ... it seems like we're not out of the woods yet. Why
> > >> is Richard's proposed test case still showing
> > >> + -> Memoize (actual rows=5000 loops=N)
> > >> +
In 5543677ec9 we introduced an optimization that uses Limit instead of
Unique to implement DISTINCT when all the DISTINCT pathkeys have been
marked as redundant. I happened to notice that this optimization was
not applied to partial DISTINCT, which I think should be. This can
improve plans in som
On Tue, Jan 23, 2024 at 5:03 PM David Rowley wrote:
> I've not caught up on the specifics of 0452b461b, but I just wanted to
> highlight that there was some work done in [1] in this area. It seems
> Ankit didn't ever add that to a CF, so that might explain why it's
> been lost.
>
> Anyway, just
On Sat, Jan 27, 2024 at 10:08 AM vignesh C wrote:
> On Mon, 8 Jan 2024 at 22:21, Tom Lane wrote:
> >
> > Richard Guo writes:
> > > On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
> > >> Thanks for the report! I guess we need something like the attached.
In [1] we've reached a conclusion that for a MATERIALIZED CTE it's okay
to 'allow our statistics or guesses for the sub-query to subsequently
influence what the upper planner does'. Commit f7816aec23 exposes
column statistics to the upper planner. In the light of that, here is a
patch that expose
On Mon, Jan 29, 2024 at 11:20 AM vignesh C wrote:
> On Mon, 29 Jan 2024 at 08:01, Richard Guo wrote:
> > On Sat, Jan 27, 2024 at 10:08 AM vignesh C wrote:
> >> I have changed the status of the commitfest entry to "Committed" as I
> >> noticed the patch has
On Mon, Jul 17, 2023 at 4:55 PM Richard Guo wrote:
> But I did not find a query that makes an incremental sort in this case.
> After trying for a while it seems to me that we do not need to consider
> incremental sort in this case, because for a partial path of a grouped
> or parti
On Sun, Jan 21, 2024 at 8:37 PM vignesh C wrote:
> I'm seeing that there has been no activity in this thread for nearly 6
> months, I'm planning to close this in the current commitfest unless
> someone is planning to take it forward. It can be opened again when
> there is more interest.
I'm pla
On Sat, Jan 27, 2024 at 11:29 AM vignesh C wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
>
> Please post an updated version for the same.
Attached is an updated patch. Nothing else has changed.
Thanks
Richard
v6-0001-Support-run-time-partition-pruning-for-hash-join.p
On Tue, Jan 30, 2024 at 7:00 PM David Rowley wrote:
> On Mon, 29 Jan 2024 at 22:39, Richard Guo wrote:
> > So in the v3 patch I've brought back the logic that considers
> > incremental sort on partial paths in gather_grouping_paths(). However,
> > I failed to co
On Wed, Jan 31, 2024 at 5:12 AM Tom Lane wrote:
> Richard Guo writes:
> > On Wed, Jan 17, 2024 at 5:01 PM Richard Guo
> wrote:
> >> Sure, here it is:
> >> v10-0001-Avoid-reparameterizing-Paths-when-it-s-not-suitable.patch
>
> > I forgot to mention th
On Wed, Jan 31, 2024 at 5:13 AM David Rowley wrote:
> On Wed, 31 Jan 2024 at 00:44, Richard Guo wrote:
> > This patchset does not aim to introduce anything new; it simply
> > refactors the existing code. The newly added tests are used to show
> > that the code that i
On Wed, Jan 31, 2024 at 12:26 PM David Rowley wrote:
> On Fri, 26 Jan 2024 at 21:14, David Rowley wrote:
> > However, having said that. Parallel plans are often picked when there
> > is some highly selective qual as parallel_tuple_cost has to be applied
> > to fewer tuples for such plans, so pro
On Wed, Jan 31, 2024 at 11:21 PM Tom Lane wrote:
> Richard Guo writes:
> > On Wed, Jan 31, 2024 at 5:12 AM Tom Lane wrote:
> >> * Why is it okay to just use pull_varnos on a tablesample expression,
> >> when contain_references_to() does something different?
>
&g
On Thu, Feb 1, 2024 at 10:04 AM James Coleman wrote:
> I don't see any inherent reason why we must always assume that
> gather_grouping_paths will always result in having at least one entry
> in pathlist. If, for example, we've disabled incremental sort and the
> cheapest partial path happens to
On Thu, Feb 1, 2024 at 11:37 AM David Rowley wrote:
> On Thu, 1 Feb 2024 at 16:29, Richard Guo wrote:
> > On Thu, Feb 1, 2024 at 10:04 AM James Coleman wrote:
> >> I don't see any inherent reason why we must always assume that
> >> gather_grouping_paths will
On Thu, Feb 1, 2024 at 3:43 PM Anthonin Bonnefoy <
anthonin.bonne...@datadoghq.com> wrote:
> Hi,
>
> I've seen a similar issue with the following query (tested on the current
> head):
>
> EXPLAIN ANALYZE SELECT * FROM tenk1 t1
> LEFT JOIN LATERAL (SELECT t1.two, tenk2.hundred, tenk2.two FROM tenk2
On Thu, Feb 1, 2024 at 5:03 PM David Rowley wrote:
> On Thu, 1 Feb 2024 at 19:36, Richard Guo wrote:
> > maybe we can add an Assert or a comment clarifying that the pathlist of
> > partially_grouped_rel cannot be empty here.
>
> There'd be no need to Assert that as se
On Fri, Feb 2, 2024 at 1:45 AM Tom Lane wrote:
> I pushed v12 (with some cosmetic adjustments) into the back branches,
> since we're getting close to the February release freeze. We still
> need to deal with the larger fix for HEAD. Please re-post that
> one so that the cfbot knows which is the
On Fri, Feb 2, 2024 at 10:02 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push this if there are no objections.
>
> One of the test cases added by this commit has not been very
> stable in the buildfarm. Latest example is here:
>
>
> https://buildfarm.postgresql.org/cgi-bin/
On Fri, Feb 2, 2024 at 11:32 AM Richard Guo wrote:
> On Fri, Feb 2, 2024 at 10:02 AM Tom Lane wrote:
>
>> One of the test cases added by this commit has not been very
>> stable in the buildfarm. Latest example is here:
>>
>>
>> https://buildfarm.postgresql
On Fri, Feb 2, 2024 at 11:26 AM David Rowley wrote:
> In light of this, do you still think it's worthwhile making this change?
>
> For me, I think all it's going to result in is extra planner work
> without any performance gains.
Hmm, with the query below, I can see that the new plan is cheaper
On Fri, Feb 2, 2024 at 2:41 PM Michael Paquier wrote:
> On Fri, Feb 02, 2024 at 11:56:36AM +0530, Amit Kapila wrote:
> > On Fri, Feb 2, 2024 at 10:58 AM Tom Lane wrote:
> >> Thanks for all the work you did running it! CFM is typically a
> >> thankless exercise in being a nag, but I thought you
On Mon, Dec 25, 2023 at 3:01 PM Richard Guo wrote:
> On Thu, Jul 13, 2023 at 3:12 PM Richard Guo
> wrote:
>
>> So I'm wondering if it'd be better that we move all this logic of
>> computing additional lateral references within PHVs to get_memoize_path,
>> wh
On Fri, Feb 2, 2024 at 6:39 PM David Rowley wrote:
> So the gains increase with more parallel workers due to pushing more
> work to the worker. Amdahl's law approves of this.
>
> I'll push the patch shortly.
Thanks for the detailed testing and pushing the patch!
Thanks
Richard
On Fri, Feb 2, 2024 at 7:36 PM David Rowley wrote:
> Now for the other stuff you had. I didn't really like this part:
>
> + /*
> + * Set target for partial_distinct_rel as generate_useful_gather_paths
> + * requires that the input rel has a valid reltarget.
> + */
> + partial_distinct_rel->relt
cfbot reminds that this patch does not apply any more. So I've rebased
it on master, and also adjusted the test cases a bit.
Thanks
Richard
v2-0001-Reordering-DISTINCT-keys-to-match-input-path-s-pathkeys.patch
Description: Binary data
... and the patches in CF #47 (currently open) are listed in 'Next
commitfest'. I guess we need to manually create a "next" commitfest?
Thanks
Richard
On Fri, Nov 24, 2023 at 6:29 AM David Rowley wrote:
> I've attached the updated patch. This one is probably ready for
> someone to test out. There will be more work to do, however.
I just started reviewing this patch and haven't looked through all the
details yet. Here are some feedbacks that
On Thu, Feb 23, 2023 at 4:50 AM Tom Lane wrote:
> I thought about this and decided that it's not really a problem.
> have_relevant_joinclause is just a heuristic, and I don't think we
> need to prioritize forming a join if the only relevant clauses look
> like this. We won't be able to use such
On Thu, Mar 2, 2023 at 6:59 AM Tom Lane wrote:
> Yeah. I split out those executor fixes as 0002; 0003 is the changes
> to bitmapsets proper, and then 0004 removes now-dead code.
+1 to all these patches. Some minor comments from me.
*0003
It seems that the Bitmapset checked by bms_is_empty_in
While looking into issue [1], I came across $subject on master. Below
is how to reproduce it.
DROP TABLE IF EXISTS t1,t2,t3,t4 CASCADE;
CREATE TABLE t1 AS SELECT true AS x FROM generate_series(0,1) x;
CREATE TABLE t2 AS SELECT true AS x FROM generate_series(0,1) x;
CREATE TABLE t3 AS SELECT true
On Fri, Mar 10, 2023 at 4:13 PM Richard Guo wrote:
> I wonder if we should consider syn_xxxhand rather than min_xxxhand in
> clause_is_computable_at when we check if clause mentions any nullable
> Vars. But I'm not sure about that.
>
No, considering syn_xxxhand is not right.
On Mon, Mar 13, 2023 at 5:03 PM Richard Guo wrote:
> Back to the original issue, if a join has more than one quals, actually
> we treat them as a whole when we check if identity 3 applies as well as
> when we adjust them to be suitable for commutation according to identity
> 3. So w
On Wed, Mar 15, 2023 at 2:25 AM Gregory Stark (as CFM)
wrote:
> So what is the status of this patch?
>
> It looks like you received some feedback from Emre, Tom, Ronan, and
> Alvaro but it also looks like you responded to most or all of that.
> Are you still blocked waiting for feedback? Anything
On Wed, Mar 15, 2023 at 6:18 PM Etsuro Fujita
wrote:
> While working on something else, I noticed that the “if (entry->conn
> == NULL)” test after doing disconnect_pg_server() when re-establishing
> a given connection in GetConnection() is pointless, because the former
> function ensures that ent
On Mon, Mar 13, 2023 at 5:44 PM Richard Guo wrote:
> On Mon, Mar 13, 2023 at 5:03 PM Richard Guo
> wrote:
>
>> Back to the original issue, if a join has more than one quals, actually
>> we treat them as a whole when we check if identity 3 applies as well as
>> when we
On Fri, Mar 17, 2023 at 6:15 AM Tom Lane wrote:
> Pushed. I thought the comment needed to be completely rewritten not just
> tweaked, and I felt it was probably reasonable to continue to exclude
> dummy paths from getting the more expensive treatment.
Yes agreed. Thanks for the changes and pu
On Mon, Jan 9, 2023 at 5:21 PM David Rowley wrote:
> On Thu, 5 Jan 2023 at 20:06, Richard Guo wrote:
> > I reviewed this patch and have some comments.
>
> Thanks for looking at this. I think I've fixed all the issues you
> mentioned.
>
> One extra thing I notice
On Mon, Mar 20, 2023 at 2:43 PM Michael Paquier wrote:
> Nathan has reported to me offlist that maintainer-clean was not doing
> its job for the files generated by gen_node_support.pl in
> src/backend/nodes/ for the query jumbling. Attached is a patch to
> take care of this issue.
>
> While on i
On Mon, Mar 20, 2023 at 3:49 PM Daniel Gustafsson wrote:
> > On 20 Mar 2023, at 08:46, Michael Paquier wrote:
> > How about removing the "fout/five" entirely here
> > and make that simpler? I would propose:
> > "For some classes of node types, you don't need all the support
> > functions."
>
>
On Tue, Mar 21, 2023 at 12:26 AM Zhang Mingli wrote:
> Found several typos like plgsql, I think it should be plpgsql.
>
+1. I believe these are typos. And a grep search shows that all typos of
this kind are addressed by the patch.
Thanks
Richard
On Tue, Mar 21, 2023 at 5:41 PM Etsuro Fujita
wrote:
> While working on something else, I noticed $SUBJECT added by commit
> 86dc90056:
>
> * For UPDATE and DELETE queries, the targetlist must also contain "junk"
> * tlist entries needed to allow the executor to identify the rows to be
> * upd
1 - 100 of 855 matches
Mail list logo
