Does it know that the input to the sort routine is already sorted and
hence is a no-op?
Yes
No, but in most cases this will use an index and hence will assume that
the index is responsible for ordering.
regards, tom lane
---(end of
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Hi,
Does PostgreSQL do the following optimisation:
SELECT * FROM diary WHERE date = '2005-05-01' ORDER BY date;
or in fact even better (for my situation)
SELECT * FROM diary WHERE date BETWEEN '2005-05-01' AND
Hannu Krosing wrote:
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Hi,
Does PostgreSQL do the following optimisation:
SELECT * FROM diary WHERE date = '2005-05-01' ORDER BY date;
or in fact even better (for my situation)
SELECT * FROM diary WHERE date BETWEEN
Christopher Kings-Lynne wrote:
Doesn't seem like it does:
usatest=# explain select * from users_myfoods_map where date='2004-11-21'
order by date;
QUERY PLAN
---
Sort (cost=17.17..17.48
Christopher Kings-Lynne said:
usatest=# explain select * from users_myfoods_map where
date='2004-11-21' order by date;
I assume that this is program generated SQL, as I hope a human would know
better than to write this. In which case, isn't the answer to improve the
generator rather than
On 7/14/05, Michael Paesold wrote:
Christopher Kings-Lynne wrote:
usatest=# explain select * from users_myfoods_map where date='2004-11-21'
order by date;
QUERY PLAN
---
Sort
Hannu Krosing [EMAIL PROTECTED] writes:
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Does it know that the input to the sort routine is already sorted and
hence is a no-op?
Yes
No, but in most cases this will use an index and hence will assume that
the index is
I assume that this is program generated SQL, as I hope a human would know
better than to write this. In which case, isn't the answer to improve the
generator rather than expect postgres to make up for its defficiencies?
Well, the issue in my case is we have user food diaries. Usually,
Does it know that the input to the sort routine is already sorted and
hence is a no-op?
Yes
No, but in most cases this will use an index and hence will assume that
the index is responsible for ordering.
OK, so what's going on here?
usa= explain select * from users_myfoods_map where
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
OK, so what's going on here?
usa= explain select * from users_myfoods_map where user_id=1 and
date='2003-11-03' order by date;
QUERY PLAN
Well, date evidently isn't the high-order key of this index. But why
exactly are you worried about a sort of 2 rows?
Aha that's nailed it:
usa= explain select * from users_myfoods_map where user_id=1 and date
between '2003-11-03' and '2003-11-03' order by user_id, date;
Hi,
Does PostgreSQL do the following optimisation:
SELECT * FROM diary WHERE date = '2005-05-01' ORDER BY date;
or in fact even better (for my situation)
SELECT * FROM diary WHERE date BETWEEN '2005-05-01' AND '2005-05-01'
ORDER BY date;
Does it know that the input to the sort routine is
12 matches
Mail list logo
