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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Lane 2011-06-29 15:06:44 Re: Order-by and indexes
Previous Message Odd Hogstad 2011-06-29 14:42:36 Re: Order-by and indexes