2015-03-03 20:32 GMT+01:00 Tom Lane :
> I wrote:
> > Robert Haas writes:
> >> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
> >>> To some extent this is a workaround for the fact that plpgsql does type
> >>> conversions the way it does (ie, by I/O rather than by using the
> parser's
> >>> cas
I wrote:
> Robert Haas writes:
>> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
>>> To some extent this is a workaround for the fact that plpgsql does type
>>> conversions the way it does (ie, by I/O rather than by using the parser's
>>> cast mechanisms). We've talked about changing that, but
On 2/28/15 11:26 PM, Tom Lane wrote:
Also, instrumenting the code showed that TypeCacheConstrCallback gets
called quite a lot during the standard regression tests, which is why
I went out of my way to make it quick. Almost all of those cache flushes
are from non-domain-related updates on pg_type
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> This is the first attempt at weaponizing the memory context
> Tom> reset/delete feature, and I'm fairly happy with it, except for one
> Tom> thing: I had to #include utils/memnodes.h into typcache.h in order
> Tom> to preserve the inten
> "Tom" == Tom Lane writes:
Tom> This is the first attempt at weaponizing the memory context
Tom> reset/delete feature, and I'm fairly happy with it, except for one
Tom> thing: I had to #include utils/memnodes.h into typcache.h in order
Tom> to preserve the intended property that the call
Andres Freund writes:
> On 2015-02-26 13:53:18 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> You're probably going to kill me because of the increased complexity,
>>> but how about making typecache.c smarter, more in the vein of
>>> relcache.c, and store the relevant info in there?
>> I th
2015-02-27 21:57 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
> >> To some extent this is a workaround for the fact that plpgsql does type
> >> conversions the way it does (ie, by I/O rather than by using the
> parser's
> >> cast mechanisms). W
Robert Haas writes:
> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
>> To some extent this is a workaround for the fact that plpgsql does type
>> conversions the way it does (ie, by I/O rather than by using the parser's
>> cast mechanisms). We've talked about changing that, but people seem to
On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
> To some extent this is a workaround for the fact that plpgsql does type
> conversions the way it does (ie, by I/O rather than by using the parser's
> cast mechanisms). We've talked about changing that, but people seem to
> be afraid of the compat
Andres Freund writes:
> On 2015-02-26 13:53:18 -0500, Tom Lane wrote:
>> I thought that's what I was proposing in point #1.
> Sure, but my second point was to avoid duplicating that information into
> ->fcinfo and such and instead reference the typecache entry from
> there. So that if the typecac
2015-02-26 19:53 GMT+01:00 Tom Lane :
> Andres Freund writes:
> > On 2015-02-26 12:31:46 -0500, Tom Lane wrote:
> >> 2. In plpgsql, explicitly model a domain type as being its base type
> >> plus some constraints --- that is, stop depending on domain_in() to
> >> enforce the constraints, and do i
On 2015-02-26 13:53:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Hm. A bit sad to open code that in plpgsql instead of making it
> > available more generally.
>
> The actual checking wouldn't be open-coded, it would come from
> domain_check() (or possibly a modified version of that). It
Andres Freund writes:
> On 2015-02-26 12:31:46 -0500, Tom Lane wrote:
>> 2. In plpgsql, explicitly model a domain type as being its base type
>> plus some constraints --- that is, stop depending on domain_in() to
>> enforce the constraints, and do it ourselves. This would mean that
>> the FmgrInf
Hi,
On 2015-02-26 12:31:46 -0500, Tom Lane wrote:
> It's really slow, because any assignment to a domain variable goes through
> the slow double-I/O-conversion path in exec_cast_value, even if no actual
> work is needed.
Hm, that's surely not nice for some types. Doing syscache lookups every
time
Hi
2015-02-26 18:31 GMT+01:00 Tom Lane :
> At the behest of Salesforce, I've been looking into improving plpgsql's
> handling of variables of domain types, which is currently pretty awful.
> It's really slow, because any assignment to a domain variable goes through
> the slow double-I/O-conversio
At the behest of Salesforce, I've been looking into improving plpgsql's
handling of variables of domain types, which is currently pretty awful.
It's really slow, because any assignment to a domain variable goes through
the slow double-I/O-conversion path in exec_cast_value, even if no actual
work i
16 matches
Mail list logo
