Are the key values really all 48 chars long? If not, you made a
bad datatype choice: varchar(n) (or even text) would be a lot
smarter. char(n) wastes space on blank-padding.
Yep, everything exactly 48. Looks like I'll be storing it as a bytea
in the near future though.
It's a good idea
Hi, David,
david drummard wrote:
1) create a new table every time a new feed file comes in. Create table
with indexes. Use the copy command to dump the data into the table.
Its faster to obey the following order:
- Create the table
- COPY the data into the table
- Create the indices
-
ok I am retarded :) Apparently I thought I had done analyze on these
tables but I actually had not and that was all that was needed. but
thanks for the help.
Tim Jones
Healthcare Project Manager
Optio Software, Inc.
(770) 576-3555
-Original Message-
From: Dave Dutcher [mailto:[EMAIL
From: Michael Fuhr
Date: 02/13/06
07:46:05
To: Adnan DURSUN
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM]
SQL Function Performance
On Sun, Feb 12, 2006 at 10:25:28PM +0200, Adnan DURSUN wrote:
My database has an SQL
From: Michael Fuhr
Date: 02/13/06
07:46:05
To: Adnan DURSUN
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] SQL
Function Performance
On Sun, Feb 12, 2006 at 10:25:28PM +0200, Adnan DURSUN wrote:
My database has an SQL function. The result comes in
From: Mark
Liberman
Date: 02/13/06
22:09:48
To: Adnan DURSUN; pgsql-performance@postgresql.org
Subject: RE: [PERFORM]
SQL Function Performance
I've run into this issue. It basically comes down to the
plan that is being used inside the function is not the same as the plan used
when you
On Mon, Feb 13, 2006 at 07:57:07PM -0500, Tom Lane wrote:
Adnan DURSUN [EMAIL PROTECTED] writes:
EXPLAIN ANALYZE EXECUTE stmt (...);
Here is the EXPLAIN ANALYZE output for prepared statement :
This is exactly the same as the other plan --- you did not parameterize
the query. To see
