From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | "ludo(at)ludikidee(dot)com" <ludo(at)ludikidee(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Preserving ORDER of TEMP Tables during transaction |
Date: | 2011-11-13 16:58:23 |
Message-ID: | 856B7950-47D7-48EF-9140-523B25DDBE9B@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Nov 13, 2011, at 11:13, Ludo Smissaert <ludo(at)ludikidee(dot)com> wrote:
> Greetings,
>
> Within a PL/PgSQL function I do a
>
> CREATE TEMPORARY TABLE v_temp ON COMMIT DROP
> AS
> SELECT ctime FROM source ORDER BY ctime
> WITH DATA;
>
> Then I use the v_temp in the same transaction block:
>
> FOR v_ctime IN
> SELECT ctime FROM v_temp
> LOOP
> ....
> END LOOP;
>
> Now I am curious, will the loop return values for ctime in the *same order*
> as the query that created the temporary table, or is this undefined?
>
> With other words: can I rely on the ORDER BY of the query that defined the temporary table? Is there a way to do that?
>
> Regards,
> Ludo Smissaert
>
>
Why risk basing your query's success on an implementation artifact? Put an explicit ORDER BY on the SELECT FROM v_temp.
Related question, though. Does the time to perform a sort vary based upon the entropy of the input data? If the original ORDER BY does result in the records being provided to sorter in order already does the sort basically finish immediately or is the algorithm strictly dependent upon the number of records to sort?
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Ludo Smissaert | 2011-11-13 19:28:52 | Re: Preserving ORDER of TEMP Tables during transaction |
Previous Message | Tom Lane | 2011-11-13 16:45:04 | Re: CLONE DATABASE (with copy on write?) |