Re: quick question abt pg_dump and restore - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject Re: quick question abt pg_dump and restore
Date
Msg-id 20080109172815.2234f0b5@webthatworks.it
Whole thread Raw
In response to Re: quick question abt pg_dump and restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: quick question abt pg_dump and restore
Re: quick question abt pg_dump and restore
List pgsql-general
On Wed, 09 Jan 2008 10:54:21 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Josh Harrison escribió:
> >> Fine. I can use order by when I want  to order it in terms of
> >> some columns. But What if I want to maintain the same order as
> >> in the database1? ie., I want my rows of TableABC in Database2
> >> to be the same order as the rows in TableABC in Database 1 ???
>
> > You can't.
>
> According to the SQL standard, a table is an *unordered* collection
> of rows, and the results of any query are produced in an
> unspecified order (unless you use ORDER BY).  The ambiguity about
> row ordering is intentional and is exploited by most DBMSes
> including Postgres to improve implementation efficiency.  If you
> assume there is such a thing as a specific ordering within a table,
> you'll live to regret it eventually.

Does it make any sense *knowing* how the implementation works to load
records in a table in a specific order to improve performances?

And yeah I know that once you start deleting/updating row you may
lose the advantage you gained betting on some peculiarity of the
implementation... but in case you're dealing with a mostly static
table?

eg. if I'm importing a table does it make any sense to pre-sort it
before importing it in postgres?

--
Ivan Sergio Borgonovo
http://www.webthatworks.it


pgsql-general by date:

Previous
From: Ivan Sergio Borgonovo
Date:
Subject: Re: count(*) and bad design was: Experiences with extensibility
Next
From: "Scott Marlowe"
Date:
Subject: Re: count(*) and bad design was: Experiences with extensibility