On Tue, Sep 1, 2015 at 6:13 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > My thought is that there's a fair amount of places where we do string > comparison for not a great reason. Perhaps a better example is data that > comes back from a trigger; AFTER/BEFORE, INSERT/UPDATE/..., which is more > expensive to setup the variables for (strdup a fixed string, which means a > palloc), and then comparisons are done as text varlena (iirc). > > Instead if this information came back as an ENUM the variable would be a > simple int as would the comparison. We'd still have a raw string being > parsed in the function body, but that would happen once during initial > compilation and it would be replaced with an ENUM value. > > For RAISE, AFAIK we still end up converting the raw string into a varlena > CONST, which means a palloc. If it was an ENUM it'd be converted to an int. > > If we're worried about the overhead of the enum machinery we could create a > relcache for system enums, but I suspect that even without that it'd be a > win over the string stuff. Especially since I bet most people run UTF8.
I agree with Pavel on this one: creating an extra type here is going to cause more pain than it removes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
