Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I don't have a problem with that, but I haven't quite convinced myself
>> that we need to expend the cycles to check for it, either ...
> I would expect that the sequential plan would be better for a volatile
> wh
On Sat, Apr 09, 2005 at 00:57:11 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I don't have a problem with that, but I haven't quite convinced myself
> that we need to expend the cycles to check for it, either ...
You could have two different aggregates and end up with values
that could happen
Neil Conway <[EMAIL PROTECTED]> writes:
> Hmm; what about
> SELECT min(x), min(x) FROM tab WHERE random() > 0.5;
> Applying the optimization would mean the two min(x) expressions would
> likely be different, which seems rather weird.
Actually not: my expectation is that identical aggregate c
Tom Lane wrote:
All that this optimization might do is to further cut the fraction of
table rows at which the volatile function actually gets checked. So
I'm not seeing that it would break any code that worked reliably before.
Hmm; what about
SELECT min(x), min(x) FROM tab WHERE random() > 0.5
Neil Conway <[EMAIL PROTECTED]> writes:
> Does this transformation work for a query of the form:
> SELECT min(x), max(y) FROM tab WHERE random() > 0.5;
I've been going back and forth on that. We wouldn't lose a lot in the
real world if we simply abandoned the optimization attempt whenever we
Tom Lane wrote:
Specifically, I'm imagining that we could convert
SELECT min(x), max(y) FROM tab WHERE ...
into sub-selects in a one-row outer query:
SELECT (SELECT x FROM tab WHERE ... ORDER BY x LIMIT 1),
(SELECT y FROM tab WHERE ... ORDER BY y DESC LIMIT 1);
Does t
On Fri, Apr 08, 2005 at 23:40:28 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > It should be possible to make this work for bool_and and bool_or as those
> > are equivalent to min and max for the boolean type.
>
> This would just be a matter of marki
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> It should be possible to make this work for bool_and and bool_or as those
> are equivalent to min and max for the boolean type.
This would just be a matter of marking them properly in the catalogs.
However, are they really equivalent in the corner cas
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Thinking about the case for NULLs some more, I am wondering if you are
> going to treat aggregates with strict state functions different than
> those that don't?
We only intend this to support MAX and MIN. If you're inventing an
aggregate that doesn't
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> SELECT (SELECT x FROM tab WHERE ... ORDER BY x LIMIT 1),
>> (SELECT y FROM tab WHERE ... ORDER BY y DESC LIMIT 1);
> Are NULLs a problem? In the second case above, wouldn't you get NULL
> instead of the value re
Looks great! I had been slowly thinking along similar lines via the
equivalence:
SELECT min(x) FROM tab WHERE...
SELECT min(x) FROM (SELECT x FROM tab WHERE ... ORDER BY x LIMIT 1) AS t
However, it looks like your approach is more flexible than this :-)
best wishes
Mark
Tom Lane wrote:
I realized
On Fri, Apr 08, 2005 at 20:50:09 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Comments? Anyone see anything I missed?
Thinking about the case for NULLs some more, I am wondering if you are
going to treat aggregates with strict state functions different than
those that don't? It seems for one
On Fri, Apr 08, 2005 at 20:50:09 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> SELECT (SELECT x FROM tab WHERE ... ORDER BY x LIMIT 1),
> (SELECT y FROM tab WHERE ... ORDER BY y DESC LIMIT 1);
> Comments? Anyone see anything I missed?
Are NULLs a problem? In the second ca
On Fri, Apr 08, 2005 at 20:50:09 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Comments? Anyone see anything I missed?
It should be possible to make this work for bool_and and bool_or as those
are equivalent to min and max for the boolean type.
---(end of broadcast)--
We've been talking about this long enough ... let's try to actually do it ...
In the last go-round, the thread starting here,
http://archives.postgresql.org/pgsql-hackers/2004-11/msg00371.php
we spent a lot of time agonizing over GROUP BY and whether the
optimization is usable for anything beside
15 matches
Mail list logo
