Re: Slow index scan on B-Tree index over timestamp field - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Slow index scan on B-Tree index over timestamp field
Date
Msg-id CAMkU=1yAyZMCPnBUZ6N_RLreWhys=owfLSuax41vf2_4aPQnbA@mail.gmail.com
Whole thread Raw
In response to Re: Slow index scan on B-Tree index over timestamp field  (Caio Casimiro <casimiro.listas@gmail.com>)
List pgsql-performance
On Mon, Nov 4, 2013 at 2:10 PM, Caio Casimiro <casimiro.listas@gmail.com> wrote:

You said that I would need B-Tree indexes on the fields that I want the planner to use index only scan, and I think I have them already on the tweet table:

"tweet_ios_index" btree (id, user_id, creation_time)

Shouldn't the tweet_ios_index be enough to make the scan over tweet_creation_time_index be a index only scan?

You can't efficiently scan an index when the first column in it is not constrained.  You would have to define the index as (creation_time, user_id, id) instead to get it to use an IOS.

 
And, more important, would it be really faster?

Probably.

Cheers,

Jeff

pgsql-performance by date:

Previous
From: Igor Neyman
Date:
Subject: Re: Slow index scan on B-Tree index over timestamp field
Next
From: Merlin Moncure
Date:
Subject: Re: Trees: integer[] outperformed by ltree