I think your first thought was good.
How high ? I think it's a matter of convention, certainly more than default
100.
czw., 21 lis 2019 o 02:05 Andy Fan napisał(a):
>
>
> On Thu, Oct 31, 2019 at 11:07 PM Tom Lane wrote:
>
>>
>>
>> Possibly this could be finessed by only trying to find duplica
On Thu, Oct 31, 2019 at 11:07 PM Tom Lane wrote:
>
>
> Possibly this could be finessed by only trying to find duplicates of
> functions that have high cost estimates. Not sure how high is high
> enough.
can we just add a flag on pg_proc to show if the cost is high or not, if
user are not happ
Hi
I need advice.
ResetExprContext(econtext) is defined as
MemoryContextReset((econtext)->ecxt_per_tuple_memory).
I can register callback in MemoryContext but it is always cleaned on every
call to MemoryContextReset().
How to reset some fields of ExprContext ( living in per_query_memory ) when
Res
Hi,
On 2019-11-03 21:56:31 +0100, Andrzej Barszcz wrote:
> Main goal of this patch is to avoid repeated calls of immutable/stable
> functions.
> This patch is against version 10.10.
> I guess same logic could be implemented up till version 12.
If you want actual development feedback, you're more
Hi
Main goal of this patch is to avoid repeated calls of immutable/stable
functions.
This patch is against version 10.10.
I guess same logic could be implemented up till version 12.
--- src/include/nodes/execnodes.h 2019-08-05 23:16:54.0 +0200
+++ src/include/nodes/execnodes.h 2019-11-03 2
Hi,
On October 31, 2019 8:51:11 AM PDT, Andrzej Barszcz wrote:
>x <> 0 is evaluated first, 1/x only when x <> 0, not ?
>
>czw., 31 paź 2019 o 16:45 Tom Lane napisał(a):
>
>> Andres Freund writes:
>> > Potentially related note: for nodes like seqscan, combining the
>qual and
>> projection proce
x <> 0 is evaluated first, 1/x only when x <> 0, not ?
czw., 31 paź 2019 o 16:45 Tom Lane napisał(a):
> Andres Freund writes:
> > Potentially related note: for nodes like seqscan, combining the qual and
> projection processing into one expression seems to be a noticable win (at
> least when tak
Hi,
On October 31, 2019 8:45:26 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> Potentially related note: for nodes like seqscan, combining the qual
>and projection processing into one expression seems to be a noticable
>win (at least when taking care do emit two different sets of deform
>exp
Andres Freund writes:
> Potentially related note: for nodes like seqscan, combining the qual and
> projection processing into one expression seems to be a noticable win (at
> least when taking care do emit two different sets of deform expression steps).
There's just one problem: that violates S
Hi,
On October 31, 2019 8:06:50 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On October 31, 2019 7:45:26 AM PDT, Tom Lane
>wrote:
>>> We've typically supposed that the cost of searching for duplicate
>>> subexpressions would outweigh the benefits of sometimes finding
>them.
>
>> Based on
Andres Freund writes:
> On October 31, 2019 7:45:26 AM PDT, Tom Lane wrote:
>> We've typically supposed that the cost of searching for duplicate
>> subexpressions would outweigh the benefits of sometimes finding them.
> Based on profiles I've seen I'm not sure that's the right choice. Both for
On 10/31/19 3:45 PM, Tom Lane wrote:
Andres Freund writes:
On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz wrote:
Any pros and cons ?
Depends on the actual way of implementing this proposal. Think we need more
details than what you idea here.
We've typically supposed that the cost
Hi
On October 31, 2019 7:53:20 AM PDT, Andres Freund wrote:
>On October 31, 2019 7:45:26 AM PDT, Tom Lane wrote:
>>We've typically supposed that the cost of searching for duplicate
>>subexpressions would outweigh the benefits of sometimes finding them.
>
>Based on profiles I've seen I'm not sure
Hi,
On October 31, 2019 7:45:26 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz
> wrote:
>>> I almost finished patch optimizing non volatile function calls.
>>>
>>> select f(t.n) from t where f(t.n) > 10 and f(t.n) < 100; needs 3
>calls
>>
Andres Freund writes:
> On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz wrote:
>> I almost finished patch optimizing non volatile function calls.
>>
>> select f(t.n) from t where f(t.n) > 10 and f(t.n) < 100; needs 3 calls
>> of
>> f() for each tuple,
>> after applying patch only 1.
>>
>>
Hi,
On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz wrote:
>Hi
>
>I almost finished patch optimizing non volatile function calls.
>
>select f(t.n) from t where f(t.n) > 10 and f(t.n) < 100; needs 3 calls
>of
>f() for each tuple,
>after applying patch only 1.
>
>Any pros and cons ?
Depends
Hi
I almost finished patch optimizing non volatile function calls.
select f(t.n) from t where f(t.n) > 10 and f(t.n) < 100; needs 3 calls of
f() for each tuple,
after applying patch only 1.
Any pros and cons ?
17 matches
Mail list logo
