From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Identifying no-op length coercions |
Date: | 2011-05-23 16:49:31 |
Message-ID: | BANLkTi=j255zX7hZCaErxQ8ADU78ZjC8wg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 23, 2011 at 12:42 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> I'd like to revive the discussion that arose during the last CommitFest over
> the proper design for identifying no-op length coercions like varchar(4) ->
> varchar(8). Here is the root of the original debate:
>
> http://archives.postgresql.org/message-id/20110109220353.GD5777@tornado.leadboat.com
>
> 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. How
many CPU cycles are we willing to spend trying to simplify x + 0 to
just x, or x * 0 to just 0? I might be missing something here, but
those strikes me as textbook examples of cases where it's not worth
slowing down the whole system to fix a query that the user could have
easily written in some less-pathological way to begin with.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-23 16:53:29 | Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. |
Previous Message | Noah Misch | 2011-05-23 16:42:34 | Identifying no-op length coercions |