From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing SQL ASSERTION |
Date: | 2018-09-25 00:51:28 |
Message-ID: | 877ejah19l.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Joe" == Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> writes:
Joe> Agreed. My assumption was that we would record in the data
Joe> dictionary the behaviour (or “polarity") of each aggregate
Joe> function with respect to the various operators. Column in
Joe> pg_aggregate? I don’t know how we’d record it exactly.
I haven't looked at the background of this, but if what you want to know
is whether the aggregate function has the semantics of min() or max()
(and if so, which) then the place to look is pg_aggregate.aggsortop.
(For a given aggregate foo(x), the presence of an operator oid in
aggsortop means something like "foo(x) is equivalent to (select x from
... order by x using OP limit 1)", and the planner will replace the
aggregate by the applicable subquery if it thinks it'd be faster.)
As for operators, you can only make assumptions about their meaning if
the operator is a member of some opfamily that assigns it some
semantics. For example, the planner can assume that WHERE x=y AND x=1
implies that y=1 (assuming x and y are of appropriate types) not because
it assumes that "=" is the name of a transitive operator, but because
the operators actually selected for (x=1) and (x=y) are both "equality"
members of the same btree operator family. Likewise proving that (a>2)
implies (a>1) requires knowing that > is a btree comparison op.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-25 00:58:07 | Re: Revoke execution permission of pg_stat_statements_reset() from pg_read_all_stats role |
Previous Message | Andres Freund | 2018-09-25 00:23:56 | Re: Proposal for Signal Detection Refactoring |