On Thu, Jul 11, 2024 at 5:18 PM Richard Guo wrote:
> Attached is an updated version of this patch.
I've pushed this patch. Thanks for all the reviews.
Thanks
Richard
On Fri, Jul 12, 2024 at 11:18 AM Andrei Lepikhov wrote:
> I'm not sure about stability of output format of AVG aggregate across
> different platforms. Maybe better to return the result of comparison
> between the AVG() and expected value?
I don't think this is a problem. AFAIK we use AVG() a lot
On 7/11/24 16:18, Richard Guo wrote:
On Fri, Jun 28, 2024 at 10:14 PM Andrei Lepikhov wrote:
I got the point about Memoize over join, but as a join still calls
replace_nestloop_params to replace parameters in its clauses, why not to
invent something similar to find Memoize keys inside specific
On Fri, Jun 28, 2024 at 10:14 PM Andrei Lepikhov wrote:
> I have reviewed v7 of the patch. This improvement is good enough to be
> applied, thought.
Thank you for reviewing this patch!
> Comment may be rewritten for clarity:
> "Determine if the clauses in param_info and innerrel's lateral_vars"
On 6/18/24 08:47, Richard Guo wrote:
On Mon, Mar 18, 2024 at 4:36 PM Richard Guo wrote:
Here is another rebase over master so it applies again. I also added a
commit message to help review. Nothing else has changed.
AFAIU currently we do not add Memoize nodes on top of join relation
paths.
On Mon, Mar 18, 2024 at 4:36 PM Richard Guo wrote:
> Here is another rebase over master so it applies again. I also added a
> commit message to help review. Nothing else has changed.
AFAIU currently we do not add Memoize nodes on top of join relation
paths. This is because the ParamPathInfos f
On Fri, Feb 2, 2024 at 5:18 PM Richard Guo wrote:
> The v4 patch does not apply any more. I've rebased it on master.
> Nothing else has changed.
>
Here is another rebase over master so it applies again. I also added a
commit message to help review. Nothing else has changed.
Thanks
Richard
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,
>> where we can examine only PHVs that are
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,
> where we can examine only PHVs that are evaluated at innerrel. And
> considering that these lateral
On Sun, Jul 9, 2023 at 12:17 PM David Rowley wrote:
> I just pushed a fix for this. Thanks for reporting it.
BTW, I noticed a typo in the comment inside paraminfo_get_equal_hashops.
foreach(lc, innerrel->lateral_vars)
{
Node *expr = (Node *) lfirst(lc);
TypeCache
On Sun, Jul 9, 2023 at 1:28 AM Tom Lane wrote:
> More generally, it's not clear to me why we should need to look inside
> lateral PHVs in the first place. Wouldn't the lateral PHV itself
> serve fine as a cache key?
Do you mean we use the lateral PHV directly as a cache key? Hmm, it
seems to
On Sun, Jul 9, 2023 at 1:28 AM Tom Lane wrote:
> Richard Guo writes:
> > Rebase the patch on HEAD as cfbot reminds.
>
> This fix seems like a mess. The function that is in charge of filling
> RelOptInfo.lateral_vars is extract_lateral_references; or at least
> that was how it was done up to now
On Sat, 8 Jul 2023 at 17:24, Paul A Jungwirth
wrote:
> One adjacent thing I noticed is that when we renamed "Result Cache" to
> "Memoize" this bit of the docs in config.sgml got skipped (probably
> because of the line break):
>
> Hash tables are used in hash joins, hash-based aggregation,
On Sun, 9 Jul 2023 at 05:28, Tom Lane wrote:
> More generally, it's not clear to me why we should need to look inside
> lateral PHVs in the first place. Wouldn't the lateral PHV itself
> serve fine as a cache key?
For Memoize specifically, I purposefully made it so the expression was
used as a c
Richard Guo writes:
> Rebase the patch on HEAD as cfbot reminds.
This fix seems like a mess. The function that is in charge of filling
RelOptInfo.lateral_vars is extract_lateral_references; or at least
that was how it was done up to now. Can't we compute these additional
references there? If n
On Tue, Jul 4, 2023 at 12:33 AM Richard Guo wrote:
>
> Rebase the patch on HEAD as cfbot reminds.
All of this seems good to me. I can reproduce the problem, tests pass,
and the change is sensible as far as I can tell.
One adjacent thing I noticed is that when we renamed "Result Cache" to
"Memoiz
On Fri, Dec 30, 2022 at 11:00 AM Richard Guo wrote:
> On Fri, Dec 9, 2022 at 5:16 PM Richard Guo wrote:
>
>> Actually we do have checked PHVs for lateral references, earlier in
>> create_lateral_join_info. But that time we only marked lateral_relids
>> and direct_lateral_relids, without remembe
On Tue, Jan 24, 2023 at 10:07 AM David Rowley wrote:
> I'm surprised to see that it's only Memoize that ever makes use of
> lateral_vars. I'd need a bit more time to process your patch, but one
> additional thought I had was that I wonder if the following code is
> still needed in nodeMemoize.c
>
On Fri, 30 Dec 2022 at 16:00, Richard Guo wrote:
>
> On Fri, Dec 9, 2022 at 5:16 PM Richard Guo wrote:
>>
>> Actually we do have checked PHVs for lateral references, earlier in
>> create_lateral_join_info. But that time we only marked lateral_relids
>> and direct_lateral_relids, without remember
On Fri, Dec 9, 2022 at 5:16 PM Richard Guo wrote:
> Actually we do have checked PHVs for lateral references, earlier in
> create_lateral_join_info. But that time we only marked lateral_relids
> and direct_lateral_relids, without remembering the lateral expressions.
> So I'm wondering whether we
20 matches
Mail list logo
