On Mon, Nov 05, 2007 at 10:09:12AM +0400, rihad wrote:
What if it's really a limited select:
select * from foo order by created_at desc limit SCREEN_AT_A_TIME;
because this is what I meant initially (sorry), would Postgres always
use index to get at sorted created_at values, so I don't
Should an index be used on a created_at timestamp column if you know you
will be using ORDER BY created_at ASC|DESC from time to time?
Yes.
Thanks. This is stated explicitly in 8.3 docs (as opposed to 8.2)
http://www.postgresql.org/docs/8.3/static/indexes-ordering.html
And you should use
rihad [EMAIL PROTECTED] writes:
You mean Postgres wouldn't *always* use created_at's index with such
access patterns on a big table (even if one exists):
select * from foo order by created_at desc;
No, it wouldn't necessarily, and that's a good thing. A full-table
indexscan can often be
You mean Postgres wouldn't *always* use created_at's index with such
access patterns on a big table (even if one exists):
select * from foo order by created_at desc;
No, it wouldn't necessarily, and that's a good thing. A full-table
indexscan can often be slower than a sort because of
Hi,
Should an index be used on a created_at timestamp column if you know you
will be using ORDER BY created_at ASC|DESC from time to time?
Thanks.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
am Sat, dem 03.11.2007, um 11:09:05 +0400 mailte rihad folgendes:
Hi,
Should an index be used on a created_at timestamp column if you know you
will be using ORDER BY created_at ASC|DESC from time to time?
Yes. And you should use EXPLAIN.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz:
