To: "Steven Flatt" <steven.flatt@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Insertion to temp table deteriorating over time 
In-reply-to: <357fa7590612181506r69a17e37x271623007f27c877@mail.gmail.com> 
References: <357fa7590612130844q58ef3ca5q31e164f9b006e0fc@mail.gmail.com>
	<11651.1166202586@sss.pgh.pa.us>
	<357fa7590612150955g1b9c733duaf000c23d28aa8af@mail.gmail.com>
	<12508.1166206006@sss.pgh.pa.us>
	<357fa7590612151026t4ae033f6w5367cac9d0b67064@mail.gmail.com>
	<13947.1166209788@sss.pgh.pa.us>
	<357fa7590612151121x5f95102fj21a96b1bdc7eb002@mail.gmail.com>
	<20792.1166211026@sss.pgh.pa.us>
	<357fa7590612180951q3da4c840l27caa82475444cfb@mail.gmail.com>
	<19298.1166464855@sss.pgh.pa.us>
	<357fa7590612181506r69a17e37x271623007f27c877@mail.gmail.com>
Comments: In-reply-to "Steven Flatt" <steven.flatt@gmail.com>
	message dated "Mon, 18 Dec 2006 18:06:04 -0500"
Date: Tue, 19 Dec 2006 03:08:56 -0500
Message-ID: <17718.1166515736@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Steven Flatt" <steven.flatt@gmail.com> writes:
> Issue #1:

> (I'm assuming there's a reasonable explanation for this.)  If I create a
> temp table with a single varchar column (or text column), do 100 inserts to
> that table, copy to a permanent table, truncate the temp table and repeat,
> the time required for the 100 inserts grows almost linearly.

I still can't reproduce this.  Using 7.4 branch tip, I did

create temp table foo(f1 varchar);
create table nottemp(f1 varchar);
\timing
insert into foo select stringu1 from tenk1 limit 100; insert into nottemp select * from foo; truncate foo;
insert into foo select stringu1 from tenk1 limit 100; insert into nottemp select * from foo; truncate foo;
... repeat several thousand times ...

and couldn't see any consistent growth in the reported times.  So either
it's been fixed since 7.4.6 (but I don't see anything related-looking in
the CVS logs), or you haven't provided all the details.

> Now the varchar columns that end up in the perm view come from the tbl
> table, but in tbl, they are defined as varchar(40).  Somehow the 40 limit is
> lost when constructing the view.

Yeah, this is a known issue with UNIONs not preserving the length info
--- which is not entirely unreasonable: what will you do with varchar(40)
union varchar(50)?  There's a hack in place as of 8.2 to keep the
length if all the union arms have the same length.

			regards, tom lane