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
Bruce Momjian writes:
> Tom Lane wrote:
>> Well, the discussion earlier in the week concluded that
>> add_missing_from=true should emit a notice in every case where
>> add_missing_from=false would fail. Do you want to argue against
>> that conclusion?
> I didn't realize that "SELECT pg_class.*"
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
Tom Lane wrote:
> Bruce Momjian writes:
> > test=> SELECT pg_class.* LIMIT 0;
> > NOTICE: adding missing FROM-clause entry for table "pg_class"
>
> > Is this what we want? I don't think so. I thought we wanted to
> > maintain the backward-compatible syntax of no FROM clause.
>
> Well,
Neil Conway wrote:
> Bruce Momjian wrote:
> > I just checked current CVS and see exactly what you describe:
> >
> > test=> SELECT pg_class.* LIMIT 0;
> > ERROR: missing FROM-clause entry for table "pg_class"
> >
> > test=> SET add_missing_from=true;
> > SET
> >
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
Hi All,
I observed an a bit strange behaviour of the Tab-completion in postgres
8.0.1
I have the following command
leda=# ALTER TABLE any_table RENAME TO
After the "TO" there is one space and the cursor is after that space
I press tab and I get
leda=# ALTER TABLE any_table RENAME TO TO
I
--On Donnerstag, April 07, 2005 20:48:12 -0400 Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
One piece of wisdom I've managed to grasp is that when Tom asks for
objections or comments, you better speak very quickly because he codes
way too fast (that, or he posts when the patch is almost ready.)
Hehe
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> OK, thats what I hoped you'd say. With a prepared query all of the
>> statements execute the same plan, so you don't need to know the exact
>> parameters.
> This isn't true in 8.0 if you are using the unnamed statement (as the
> JDB
21 matches
Mail list logo
