From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE 3: add facility to identify further no-work cases |
Date: | 2011-01-26 20:47:27 |
Message-ID: | AANLkTikYMzmr1SZwE64pLeRC=XT=xUb1chjLmU6hDF8V@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If you didn't mind inverting the sense of the result
>>> then we could use "EXECUTE IF function_name".
>
>> What about borrowing from the trigger syntax?
>
>> WITH FUNCTION function_name (argument_type, [...]) WHEN
>> function_that_returns_true_when_the_call_is_needed
>
> That's a good thought. Or we could use WHEN NOT check_function if you
> want to keep to the negative-result semantics.
Seems a bit contorted; I don't see any particular reason to prefer
positive vs negative semantics in this case.
>>> One point worth making here is that eval_const_expressions() does not
>>> currently care very much whether a function call came from cast syntax
>>> or explicitly. It might be worth thinking about whether we want to have
>>> a generic this-function-call-is-a-no-op simplifier hook available for
>>> *all* functions not just those that are casts. I'm not sure we want to
>>> pay the overhead of another pg_proc column, but it's something to think
>>> about.
>
>> 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. I've never
> wanted to inject such datatype-specific knowledge directly into the
> planner, but if we viewed it as function-specific knowledge supplied by
> a per-function helper routine, maybe it would fly. Knowing that a cast
> function does nothing useful for particular cases could be seen as a
> special case of this type of simplification.
Oh, I see. The times I've seen an issue with those kinds of
expressions have always been related to selectivity estimation. For
example, you'd like to get a selectivity estimate of 1-nullfrac for
(x+0)=x and 0 for (x+1)=x, and maybe (1-nullfrac)/2 for (x%2)=0. This
would only handle the first of those cases, so I'm inclined to think
it's too weak to have much general utility. The casting cases can, I
think, have a much larger impact - they occur more often in practice,
and if you can (e.g.) avoid an entire table rewrite, that's a pretty
big deal.
Another semi-related problem case I've run across is that CASE WHEN
... THEN 1 WHEN ... THEN 2 END ought to be known to only ever emit 1
and 2, and the selectivity of comparing that to some other value ought
to be computed on that basis. But now I'm really wandering off into
the weeds.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-01-26 20:48:19 | Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction. |
Previous Message | Dan Ports | 2011-01-26 20:46:22 | Re: SSI patch version 14 |