From: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: statistics about tamp tables ... |
Date: | 2003-11-26 16:34:28 |
Message-ID: | 3FC4D614.7050307@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at> writes:
>
>>Recently I have come across a simple issue which made me think about it.
>>When we create a tmp table (SELECT INTO, CREATE TABLE AS) the planner
>>won't know anything about its content after creating it.
>
>
> Run ANALYZE on the temp table, if you intend to use it enough to justify
> gathering stats about it. VACUUM is more work than needed.
>
> regards, tom lane
Of course, VACUUM is on overkill (there is no use to shrink something
minimal ;) ).
The reason why I came up with this posting is slightly different: Assume
a JDBC application which works with PostgreSQL + some other database. If
you want to use both databases without PostgreSQL being unnecessarily
slow an implicit mechanism would be better. Because otherwise you will
have an SQL command in there which is off standard - putting a switch
into the application seems to be a fairly ugly solution.
regards,
Hans
--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-11-26 16:59:33 | Re: detecting poor query plans |
Previous Message | Larry Rosenman | 2003-11-26 16:32:57 | Re: 7.4final regression failure on uw713 |