Skip site navigation (1) Skip section navigation (2)

Re: Order-by and indexes

From: "Jean-Yves F(dot) Barbier" <12ukwn(at)gmail(dot)com>
To: Odd Hogstad <odd(dot)hogstad(at)smartm(dot)no>
Cc: "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Order-by and indexes
Date: 2011-06-29 15:02:54
Message-ID: 20110629170254.2a505902@anubis.defcon1 (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
On Wed, 29 Jun 2011 16:42:36 +0200, Odd Hogstad <odd(dot)hogstad(at)smartm(dot)no> wrote:

> By default, B-tree indexes store their entries in ascending order with nulls
> last. This means that a forward scan of an index on column x produces output
> satisfying ORDER BY x (or more verbosely, ORDER BY x ASC NULLS LAST). The
> index can also be scanned backward, producing output satisfying ORDER BY x
> DESC (or more verbosely, ORDER BY x DESC NULLS FIRST, since NULLS FIRST is
> the default for ORDER BY DESC).
> Doesn't this mean that when I'm not using the order by clause, and it uses a
> Index Scan, I will always get the latest value in return?

Yes, but you're ordering by column id while you seek value into column fk.

This is very different from the doc you quote: in your case, ordering by id
returns you all values of fk BUT the ordering of fk is absolutely undefined.

And, as I suppose fk stands for Foreign Key, you have many row using same
values for fk (?)

> Also I don't
> understand why the order by query is scanning backwards, when the record I
> want is in the other end?

Because id is the primary key (I guess:) and ordering DESC puts id latest
rows first in list, so limiting select to 1 returns the last one.

BOFH excuse #287:
Telecommunications is downshifting.

In response to


pgsql-novice by date

Next:From: Tom LaneDate: 2011-06-29 15:06:44
Subject: Re: Order-by and indexes
Previous:From: Odd HogstadDate: 2011-06-29 14:42:36
Subject: Re: Order-by and indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group