Querying by range in your B-tree index's leading edge, PostgreSQL - oracle

Question

If you query for a range of dates and another thing, is having the date column as a leading edge in your index a bad thing?
I'm using PostgreSQL, but assume this applies to all B-tree indexes.
Let's say I queried for records where the created date was 2013-01-02 or later and the status is Active. I'm fuzzy on how a B-tree index would organize dates, but here's how I imagine it. If the index was on (created, status), it would be structured roughly like this:
created status
------------------------
2013-01-01 Active
2013-01-01 Inactive
2013-01-02 Active <-- This record is selected
2013-01-02 Inactive
2013-01-03 Active <-- This non-adjacent record is selected (SLOW)
2013-01-03 Inactive
If the index was on (status, created):
status created
------------------------
Active 2013-01-01
Active 2013-01-02 <-- This record is selected
Active 2013-01-03 <-- This adjacent record is selected (FAST)
Inactive 2013-01-01
Inactive 2013-01-02
Inactive 2013-01-03
So in my mind, if you used a date as a leading edge and query for a range of those dates, then records you want would be fragmented in the index, leading to poorer performance. It's even worse with a datetime.

Answer 1

I think your best best here is to use an expression index. It sounds like you will mostly be running queries such as:
select * from my_table where status='Active' and created_date > whatever
If that is the case, you would likely see the best performance by creating the index on creation date, filtered by status:
CREATE INDEX active_status_created_idx on my_table(created) WHERE status='Active'
That will result in a significantly smaller index that can be used for any queries including the WHERE status='Active' clause.
See:
https://devcenter.heroku.com/articles/postgresql-indexes#expression-indexes and
http://www.postgresql.org/docs/9.2/static/indexes-expressional.html

Answer 2

You have it all correct in your assumptions insofar as I read. You should pick your index according to the types of queries you're going to do most.
If you're doing a lot of where status = ? order by created limit 10 or order by status, created limit 10, then an index on (status, created) is usually in order.
If you're doing a lot of where created = ? order by status limit 10 or order by created, status limit 10, then you'll typically want an index on (created, status) instead.
Note that Postgres allows explicit sorting for indexes too, e.g. (created, status desc). The docs provide a lengthy discussion on why this is sometimes desirable. (I can't recall where exactly, but I'm sure you've found it already considering how you phrased your question.)
Also note the limit in each case. Usage of the index for the ordering clause depends on the number of rows that you're retrieving. Fetch enough rows and Postgres may prefer to ignore your carefully created index altogether, and top-n sort of rows retrieved through other means instead.
Lastly, note that Postgres is quite good, especially in recent versions, at managing multiple independent indexes on a single column. In fact, there is a discussion in the manual's chapters related to indexes that discusses precisely this point.
If you've an index on (created) and another on (status), it'll know to do a bitmap index scan on queries such as where status = ? and/or created = ? when both are selective enough. Along the same lines, it'll know to simply use the index on (created) for queries such as where status = ? order by created limit 10, and filter out rows where the status doesn't have the right value.