Re: Insertion to temp table deteriorating over time - Mailing list pgsql-performance

From Tom Lane
Subject Re: Insertion to temp table deteriorating over time
Date
Msg-id 17718.1166515736@sss.pgh.pa.us
Whole thread Raw
In response to Re: Insertion to temp table deteriorating over time  ("Steven Flatt" <steven.flatt@gmail.com>)
Responses Re: Insertion to temp table deteriorating over time
List pgsql-performance
"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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Next
From: "Jeremy Haile"
Date:
Subject: Inner join vs where-clause subquery