Poor use of caching in rangetypes code - Mailing list pgsql-hackers

From Tom Lane
Subject Poor use of caching in rangetypes code
Date
Msg-id 18692.1321212743@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
While digging around for the cause of the buildfarm failures in the new
rangetypes code, I noticed that range_gettypinfo thinks it can memcpy
the result of fmgr_info().  This is not cool.  It's true that fn_extra
is likely to be NULL at the instant the copy occurs, but what will
happen if the called function is using fn_extra is that on *each call*
it will have to re-create whatever data it's caching there.  That's not
only bad for performance but it means a per-call memory leak.

It looks like the reason that it's done this way is that some functions
call range_gettypinfo twice, presumably for types that could be
different ... but if they actually were different, then again the
caching would be counterproductive.

I think we need to fix this so that a cached RangeTypeInfo is used
in-place.  The places that need two of them will need some extra code
to set up a two-RangeTypeInfo cache area.

Unless you see a hole in this analysis, I will go make the changes.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: why do we need two snapshots per query?
Next
From: Tom Lane
Date:
Subject: Cause of intermittent rangetypes regression test failures