On Mon, Apr 18, 2011 at 6:25 AM, Jesper Krogh jes...@krogh.cc wrote:
Getting the value for the first sortkey and carrying on a closure
for the rest would mostly (very often) be optimal ?
Well that might depend. The input data to the function might be much
larger than the output. Consider the,
On 2011-04-18 11:00, Greg Stark wrote:
On Mon, Apr 18, 2011 at 6:25 AM, Jesper Kroghjes...@krogh.cc wrote:
Getting the value for the first sortkey and carrying on a closure
for the rest would mostly (very often) be optimal ?
Well that might depend. The input data to the function might be much
On Mon, Apr 18, 2011 at 5:38 PM, Jesper Krogh jes...@krogh.cc wrote:
order by case when (complex expresssion) 1 when (complex expression) 2
else 3
How come that expression be relevant? There is only one sortkey and no
limit, so no matter what it should clearly get the full resultset in all
Greg Stark gsst...@mit.edu writes:
A lot of SQL queries end up being written with GROUP BY primary_key,
other_column, other_column, other_column just to get those other
columns to be queryable. If we implemented the SQL standard
dependent columns feature this would be unnecessary but we don't
Excerpts from Greg Stark's message of lun abr 18 15:47:03 -0300 2011:
A lot of SQL queries end up being written with GROUP BY primary_key,
other_column, other_column, other_column just to get those other
columns to be queryable. If we implemented the SQL standard
dependent columns feature
On 2011-04-09 18:54, Tom Lane wrote:
I think that would be a positive disimprovement. The current design
guarantees that volatile sort expressions are evaluated exactly once,
in the order the rows are read from the data source. There would be no
guarantees at all, either as to the number of
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where id 3 order
by id;
id
1
2
(2 rows)
Time: 0.328 ms
2011-04-09 15:18:11.936 testdb=# CREATE or Replace FUNCTION testsort(id
integer) returns integer as $$ BEGIN
On Sat, Apr 09, 2011 at 03:22:14PM +0200, Jesper Krogh wrote:
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where id 3
order by id;
id
1
2
(2 rows)
Time: 0.328 ms
2011-04-09 15:18:11.936 testdb=# CREATE
How would PostgreSQL know that sorting by id leaves no ambiguity for
the next key to address?
It wouldn't But it could postpone evaluation until ambiguity was actually
met.
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sat, Apr 09, 2011 at 09:17:10AM -0700, David Fetter wrote:
2011-04-09 15:18:22.138 testdb=# select id from test1 where id 3
order by id,testsort(id);
id
1
2
(2 rows)
Time: 3001.896 ms
It seems strange that there is a need to evaluate testsort(id) at
all in
On 09.04.2011 19:17, David Fetter wrote:
On Sat, Apr 09, 2011 at 03:22:14PM +0200, Jesper Krogh wrote:
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where id 3
order by id;
id
1
2
(2 rows)
Time: 0.328 ms
Martijn van Oosterhout klep...@svana.org writes:
On Sat, Apr 09, 2011 at 09:17:10AM -0700, David Fetter wrote:
It seems strange that there is a need to evaluate testsort(id) at
all in this case.
How would PostgreSQL know that sorting by id leaves no ambiguity for
the next key to address?
On Sat, Apr 09, 2011 at 07:24:15PM +0300, Heikki Linnakangas wrote:
On 09.04.2011 19:17, David Fetter wrote:
On Sat, Apr 09, 2011 at 03:22:14PM +0200, Jesper Krogh wrote:
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where
On 2011-04-09 20:00, David Fetter wrote:
Given the horrors query generators perpetrate, it might be worth
dropping provably redundant ORDER BYs on the floor at planning time.
Well, many people often add a secondary sort-key to their SQL
for the only purpose of obtainting a consistent result in
On 2011-04-09 18:54, Tom Lane wrote:
I think that would be a positive disimprovement. The current design
guarantees that volatile sort expressions are evaluated exactly once,
in the order the rows are read from the data source. There would be no
guarantees at all, either as to the number of
15 matches
Mail list logo
