rmrodrig...@carto.com writes:
> This commit is breaking some Postgis tests with custom types.
Hm, yeah, the code fails to consider the possibility that the function
returns a composite type.
For the moment I'm just going to make it punt if the function result
class isn't TYPEFUNC_SCALAR. In prin
Hi,
This commit is breaking some Postgis tests with custom types.
Here is a minimal repro (Postgis not required)
```
-- test custom types
create type t_custom_type AS (
valid bool,
reason varchar,
location varchar
);
create or replace function f_immutable_custom_type(i integer)
returns t_custom
Anastasia Lubennikova writes:
> Thank you for pointing out on specific of int4() function,
> I updated tests to use dummy plpgsql function.
> I'm not sure if tests of various join types are redundant but I left them.
> As far as I understand, the principal motivation of this patch was to
> optimi
26.07.2019 21:26, Tom Lane wrote:
I took a quick look at this and I have a couple of gripes ---
* The naming and documentation of transform_const_function_to_result
seem pretty off-point to me. ISTM the real goal of that function is to
pull up constant values from RTE_FUNCTION RTEs. Replacing
I wrote:
> * It would be useful for the commentary to point out that in principle we
> could pull up any immutable (or, probably, even just stable) expression;
> but we don't, (a) for fear of multiple evaluations of the result costing
> us more than we can save, and (b) because a primary goal is to
Anastasia Lubennikova writes:
> New version is in attachments.
I took a quick look at this and I have a couple of gripes ---
* The naming and documentation of transform_const_function_to_result
seem pretty off-point to me. ISTM the real goal of that function is to
pull up constant values from R
23.07.2019 14:36, Anastasia Lubennikova :
08.07.2019 4:18, Thomas Munro:
The July Commitfest is here. Could we please have a rebase of this
patch?
Updated patch is in attachments.
I've only resolved one small cosmetic merge conflict.
Later this week I'm going to send a more thoughtful review.
08.07.2019 4:18, Thomas Munro:
The July Commitfest is here. Could we please have a rebase of this patch?
Updated patch is in attachments.
I've only resolved one small cosmetic merge conflict.
Later this week I'm going to send a more thoughtful review.
--
Anastasia Lubennikova
Postgres Profess
On Thu, Mar 21, 2019 at 5:58 AM Alexander Kuzmenkov
wrote:
> On 11/16/18 22:03, Tom Lane wrote:
> > A possible fix for this is to do eval_const_expressions() on
> > function RTE expressions at this stage (and then not need to
> > do it later), and then pull up only when we find that the
> > RTE ex
On 11/16/18 22:03, Tom Lane wrote:
A possible fix for this is to do eval_const_expressions() on
function RTE expressions at this stage (and then not need to
do it later), and then pull up only when we find that the
RTE expression has been reduced to a single Const.
Attached is a patch that doe
On 3/5/19 20:22, David Steele wrote:
I'll close this on March 8th if there is no new patch.
This is taking longer than expected. I'll move it to the next commitfest
and continue working on the patch.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postg
On 2/28/19 4:27 PM, Alexander Kuzmenkov wrote:
On 2/18/19 03:20, Tom Lane wrote:
The dummy-relation stuff I referred to has now been merged, so there's
really no good reason not to revise the patch along that line.
I'll try to post the revised implementation soon.
I'll close this on March 8
On 2/18/19 03:20, Tom Lane wrote:
The dummy-relation stuff I referred to has now been merged, so there's
really no good reason not to revise the patch along that line.
I'll try to post the revised implementation soon.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
T
Andres Freund writes:
> Given this I think the appropriate state of the CF entry would have been
> waiting-for-author, not needs review. Or alternatively
> returned-with-feedback or rejected. I'm a bit confused as to why the
> patch was moved to the next CF twice?
We have this review from Antoni
On 2018-11-08 15:08:03 +0100, Antonin Houska wrote:
> Aleksandr Parfenov wrote:
>
> > I fixed a typo and some comments. Please find new version attached.
>
> I've checked this verstion too.
>
> * is_simple_stable_function()
>
> instead of fetching HeapTuple from the syscache manually, you migh
Aleksandr Parfenov writes:
> [ funcscan_plan_optimizer_v4.patch ]
A small note here --- this would be noticeably cleaner if removal of
the no-longer-needed function RTE were done using the dummy-relation
infrastructure I proposed in
https://commitfest.postgresql.org/20/1827/
Maybe we should get
Aleksandr Parfenov wrote:
> I fixed a typo and some comments. Please find new version attached.
I've checked this verstion too.
* is_simple_stable_function()
instead of fetching HeapTuple from the syscache manually, you might want to
consider using functions from lsyscache.c (get_func_rettype,
Kyotaro HORIGUCHI wrote:
> I had the following error with the following query.
>
> =# explain select * from pg_stat_get_activity(NULL) a join log(10.0) p on
> a.pid = p.p;
> ERROR: no relation entry for relid 2
>
I think that the problem is that RTE_VALUES is wrapped in a subquery by par
Hello.
# It might be better that you provided self-contained test case.
As the discussion between Heikki and Tom just upthread, it would
be doable but that usage isn't typical. The query would be
normally written as followings and they are transformed as
desired.
select '|'||subject||'|', ts_ran
Hi,
Thank you for the review.
I fixed a typo and some comments. Please find new version attached.
---
Best regards,
Parfenov Aleksandr
On Fri, 19 Oct 2018 at 16:40, Anthony Bykov wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: teste
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hello,
I was trying to review your patch, but I couldn't install it:
pr
On Tue, 10 Jul 2018 17:34:20 -0400
Tom Lane wrote:
>Heikki Linnakangas writes:
>> But stepping back a bit, it's a bit weird that we're handling this
>> differently from VALUES and other subqueries. The planner knows how
>> to do this trick for simple subqueries:
>
>> postgres=# explain select
Heikki Linnakangas writes:
> But stepping back a bit, it's a bit weird that we're handling this
> differently from VALUES and other subqueries. The planner knows how to
> do this trick for simple subqueries:
> postgres=# explain select * from tenk1, (select abs(100)) as a (a) where
> unique1 <
On 16/05/18 13:47, Aleksandr Parfenov wrote:
Hello,
I reworked a patch to make more stable in different cases. I decided to
use simplify_function instead of eval_const_expression to prevent
inlining of the function. The only possible outputs of the
simplify_function are Const node and NULL.
Hm
Hello,
I reworked a patch to make more stable in different cases. I decided to
use simplify_function instead of eval_const_expression to prevent
inlining of the function. The only possible outputs of the
simplify_function are Const node and NULL.
Also, I block pre-evaluation of functions with typ
> "Aleksandr" == Aleksandr Parfenov writes:
>> From an implementation point of view your patch is obviously broken
>> in many ways (starting with not checking varattno anywhere, and not
>> actually checking anywhere if the expression is volatile).
Aleksandr> The actual checking if the ex
Hello Andrew,
Thank you for the review of the patch.
On Fri, 04 May 2018 08:37:31 +0100
Andrew Gierth wrote:
> From an implementation point of view your patch is obviously broken in
> many ways (starting with not checking varattno anywhere, and not
> actually checking anywhere if the expression
> "Aleksandr" == Aleksandr Parfenov writes:
Aleksandr> The idea of the fix for this situation is to check is a
Aleksandr> result of the function constant or not during the planning
Aleksandr> of the query. Attached patch does this by processing Var
Aleksandr> entries at planner stage and
28 matches
Mail list logo
