On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> It's not obvious to me that it has a use case outside of casts, but >>>> it's certainly possible I'm missing something. > >>> A possible example is simplifying X + 0 to X, or X * 0 to 0. > >> Oh, I see. The times I've seen an issue with those kinds of >> expressions have always been related to selectivity estimation. > > Yeah, helping the planner recognize equivalent cases is at least as > large a reason for wanting this as any direct savings of execution time.
Agreed. > I don't mind confining the feature to casts to start with, but it might > be a good idea to specify the check-function API in a way that would let > it be plugged into a more generally available call-simplification hook > later. Got any suggestions? My thought was that it should just get (type, typemod, type, typemod) and return a boolean. We could do something more complicated, like Expr -> Expr, but I'm pretty unconvinced there's any value there. I'd like to see some kind of appropriate hook for interjecting selectivity estimates for cases that we currently can't recognize, but my gut feeling is that that's insufficiently related at the problem at hand to worry about it. -- 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
