Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Hm. We intentionally allow SQL functions to be marked as less
> Tom> mutable than their internals, because sometimes that's useful for
> Tom> tricking the planner. However, IIRC we don't inline when we see
> Tom> that's the case. Maybe
Robert Haas writes:
> On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote:
>> Alternatively, could we postpone the parallelism checks till after
>> function inlining? Do we even make any before that?
> ... I believe the parallel-safety checks are done very early, and if
> you decide that it's not
On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote:
> Hm. We intentionally allow SQL functions to be marked as less mutable
> than their internals, because sometimes that's useful for tricking
> the planner. However, IIRC we don't inline when we see that's the
> case. Maybe there needs to be a
> "Tom" == Tom Lane writes:
Tom> Hm. We intentionally allow SQL functions to be marked as less
Tom> mutable than their internals, because sometimes that's useful for
Tom> tricking the planner. However, IIRC we don't inline when we see
Tom> that's the case. Maybe there needs to be a
On Mon, Nov 26, 2018 at 11:20 PM Andrew Gierth
wrote:
> But the combination of inlining and polymorphism, in particular, makes
> it impossible for the function author to know this. Take the OP's
> example; it is parallel safe if and only if the selected type's equal
> function is parallel safe -
Robert Haas writes:
> On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth
> wrote:
>> I'm a bit more concerned by the fact that inlining the function isn't
>> affecting the parallel safety of the query - the fact that parallel
>> safety is being checked prior to inlining means that if inlining
>>
> "Robert" == Robert Haas writes:
>> I'm a bit more concerned by the fact that inlining the function
>> isn't affecting the parallel safety of the query - the fact that
>> parallel safety is being checked prior to inlining means that if
>> inlining *introduces* a parallel hazard, it will
On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth
wrote:
> I'm a bit more concerned by the fact that inlining the function isn't
> affecting the parallel safety of the query - the fact that parallel
> safety is being checked prior to inlining means that if inlining
> *introduces* a parallel hazard,
On Mon, Nov 26, 2018 at 7:47 PM Vik Fearing wrote:
> > I'm way less inclined to buy into the idea that it MUST be wrong, though.
> > Immutability is a promise about result stability and lack of side effects,
> > but it is not a promise about implementation details. There could be an
> >
I'm a bit more concerned by the fact that inlining the function isn't
affecting the parallel safety of the query - the fact that parallel
safety is being checked prior to inlining means that if inlining
*introduces* a parallel hazard, it will go unnoticed?
--
Andrew (irc:RhodiumToad)
On 27/11/2018 01:40, Tom Lane wrote:
> Vik Fearing writes:
>> On 27/11/2018 01:13, Stephen Frost wrote:
>>> Parallel safe functions should be marked as such. Immutable functions
>>> should be marked as such. We should not assume that one implies the
>>> other, nor should we operate as if they
Vik Fearing writes:
> On 27/11/2018 01:13, Stephen Frost wrote:
>> Parallel safe functions should be marked as such. Immutable functions
>> should be marked as such. We should not assume that one implies the
>> other, nor should we operate as if they do.
> Yes we should! Unless you can
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:13, Stephen Frost wrote:
> > Parallel safe functions should be marked as such. Immutable functions
> > should be marked as such. We should not assume that one implies the
> > other, nor should we operate as if they
FWIW, I'm inclined to think that pg_config should be marked as stable
not immutable. Aside from the minor-version-upgrade issue, what if
you install new binaries that are the same version but built with
different configure flags?
The pg_config outputs are roughly as stable as initdb-inserted
Hi,
On 2018-11-27 01:27:41 +0100, Vik Fearing wrote:
> On 27/11/2018 01:13, Stephen Frost wrote:
> > Parallel safe functions should be marked as such. Immutable functions
> > should be marked as such. We should not assume that one implies the
> > other, nor should we operate as if they do.
>
>
On 27/11/2018 01:13, Stephen Frost wrote:
> Parallel safe functions should be marked as such. Immutable functions
> should be marked as such. We should not assume that one implies the
> other, nor should we operate as if they do.
Yes we should! Unless you can produce a case where an immutable
On 27/11/2018 01:14, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:10, Stephen Frost wrote:
>>> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
On 27/11/2018 01:05, Stephen Frost wrote:
> That said, I do *not* think we
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:13:17 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > > > Agreed, but I could see us having a regression test which complains if
> > >
On 2018-11-26 19:13:17 -0500, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > > Agreed, but I could see us having a regression test which complains if
> > > it finds any which are marked as immutable but
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:10, Stephen Frost wrote:
> > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> >> On 27/11/2018 01:05, Stephen Frost wrote:
> >>> That said, I do *not* think we should make any assumptions here- users
> >>>
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> > Agreed, but I could see us having a regression test which complains if
> > it finds any which are marked as immutable but aren't parallel safe.
>
> That doesn't help if a user writes a
On 27/11/2018 01:10, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 27/11/2018 01:05, Stephen Frost wrote:
>>> That said, I do *not* think we should make any assumptions here- users
>>> incorrectly mark things all the time but we shouldn't encourage
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 27/11/2018 01:05, Stephen Frost wrote:
> > That said, I do *not* think we should make any assumptions here- users
> > incorrectly mark things all the time but we shouldn't encourage that and
> > we shouldn't assume that functions
Hi,
On 2018-11-26 19:05:02 -0500, Stephen Frost wrote:
> Agreed, but I could see us having a regression test which complains if
> it finds any which are marked as immutable but aren't parallel safe.
That doesn't help if a user writes a query to review the not parallel
safe functions in their
On 27/11/2018 01:05, Stephen Frost wrote:
> That said, I do *not* think we should make any assumptions here- users
> incorrectly mark things all the time but we shouldn't encourage that and
> we shouldn't assume that functions marked as immutable are parallel
> safe.
Does that mean we also
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-27 00:47:47 +0100, Vik Fearing wrote:
> > On 27/11/2018 00:39, Andres Freund wrote:
> > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> > >> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> > >>> I was wondering what is the
On 2018-11-27 00:47:47 +0100, Vik Fearing wrote:
> On 27/11/2018 00:39, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> >> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> >>> I was wondering what is the reason IMMUTABLE functions are not by
> >>> default
On 27/11/2018 00:39, Andres Freund wrote:
> Hi,
>
> On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
>> On 26/11/2018 22:23, Gajus Kuizinas wrote:
>>> I was wondering what is the reason IMMUTABLE functions are not by
>>> default PARALLEL SAFE and if the default behaviour could be changed to
>>>
Hi,
On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> > I was wondering what is the reason IMMUTABLE functions are not by
> > default PARALLEL SAFE and if the default behaviour could be changed to
> > make IMMUTABLE functions PARALLEL SAFE?
>
> I
On 26/11/2018 22:23, Gajus Kuizinas wrote:
> I was wondering what is the reason IMMUTABLE functions are not by
> default PARALLEL SAFE and if the default behaviour could be changed to
> make IMMUTABLE functions PARALLEL SAFE?
I think I have to concur with this. When is an immutable function not
I have defined a function "is_not_distinct" for the purpose of creating a
custom operator "===".
CREATE FUNCTION is_not_distinct(a anyelement, b anyelement)
returns boolean
language sql as $$
select a is not distinct from b;
$$
IMMUTABLE;
CREATE OPERATOR === (
LEFTARG = anyelement,
31 matches
Mail list logo
