default select ordering

[Matt Roberts]

Please accept my apologies if this is answered elsewhere in the archives
or docs but I have searched without luck.

I've always assumed that default ordering of selects are based on a first
in first out principle and that this remains true at the row level despite
edits to columns.

However I'm dealing with a case where this doesn't seem to hold true. The
ordering has changed over time. Its difficult for me to gauge whether the
data has been moved around with pg_dump or whether optimisation/vacuum
commands have been called but I'm wondering if either of these things
could effect the first in first out ordering and if there's any system
tables or configerations that I can use to either verify or prevent this.

Any help greaty appreciated.

Matt Roberts

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Doug McNaught]

Matt Roberts <ma**@runtime-collective.com> writes:

Please accept my apologies if this is answered elsewhere in the archives
or docs but I have searched without luck.

I've always assumed that default ordering of selects are based on a first
in first out principle and that this remains true at the row level despite
edits to columns.

There is no guaranteed ordering of rows without an ORDER BY clause.
VACUUM will change the row ordering as it moves tuples around to free
up space. If you want a guaranteed order, use a key field and ORDER BY.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org