Re: Identifying no-op length coercions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 23, 2011 at 12:42 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> There were two proposals on the table:
>>
>> 1. Attach a "f(from_typmod, to_typmod, is_explicit) RETURNS boolean" function
>> to the pg_cast; call it in find_coercion_pathway()
>> 2. Attach a "f(FuncExpr) RETURNS Expr" (actually internal/internal) function
>> to the pg_proc; call it in simplify_function()
>>
>> I tried and failed to write a summary of the respective arguments that could
>> legitimately substitute for (re-)reading the original thread, so I haven't
>> included one. I myself find the advantages of #2 mildly more compelling.

> The main reason I preferred #1 is that it would only get invoked in
> the case of casts, whereas #2 would get invoked for all function
> calls. For us to pay that overhead, there has to be some use case,
> and I didn't find the examples that were offered very compelling.

Well, as I pointed out in
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02570.php
a hook function attached to pg_proc entries would cost nothing
measurable when not used. You could possibly make the same claim
for attaching the hook to pg_cast entries, if you cause the optimization
to occur during initial cast lookup rather than expression
simplification. But I remain of the opinion that that's the wrong place
to put it.

> How
> many CPU cycles are we willing to spend trying to simplify x + 0 to
> just x, or x * 0 to just 0?

I'm not sure that's worthwhile either, but it was an example of a
possible future use-case rather than something that anybody was
proposing doing right now. Even though I tend to agree that it wouldn't
be worth looking for such cases with simple numeric datatypes, it's not
that hard to believe that someone might want the ability for complicated
datatypes with expensive operations.

In the short term, the only actual cost we'd incur is that we'd be
bloating pg_proc instead of pg_cast with an extra column, and there's
more rows in pg_proc. But pg_proc rows are already pretty darn wide.

regards, tom lane