From: Tom Lane <tgl@sss.pgh.pa.us>
To: Steven Flatt <steven.flatt@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Insertion to temp table deteriorating over time
Date: Tue, 19 Dec 2006 03:08:56 -0500
Message-ID: <17718.1166515736@sss.pgh.pa.us> (raw)
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>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, steven.flatt@gmail.com
Subject: Re: Insertion to temp table deteriorating over time
In-Reply-To: <17718.1166515736@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox