| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert DiFalco <robert(dot)difalco(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Efficiently query for the most recent record for a given user |
| Date: | 2013-08-07 19:05:48 |
| Message-ID: | 20130807190548.GK10718@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Claudio Freire escribió:
> On Wed, Aug 7, 2013 at 3:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Note that there's no particular need to specify "desc" in the index
> > definition. This same index can support searches in either direction
> > on the "called" column.
>
> Yeah, but it's faster if it's in the same direction, because the
> kernel read-ahead code detects sequential reads, whereas it doesn't
> when it goes backwards. The difference can be up to a factor of 10 for
> long index scans.
That might be true when an index is new, but as it grows, the leaf pages
are not going to be sequential anymore. And this doesn't much apply for
an equality lookup anyway, does it?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2013-08-07 19:13:48 | Re: Efficiently query for the most recent record for a given user |
| Previous Message | Tom Lane | 2013-08-07 19:04:09 | Re: Efficiently query for the most recent record for a given user |