Re: Insert performance for large transaction with multiple COPY FROM - Mailing list pgsql-performance

From Horst Dehmer
Subject Re: Insert performance for large transaction with multiple COPY FROM
Date
Msg-id 0E6B7417-72C9-42A3-86F9-A080ADCFB2C7@gmail.com
Whole thread Raw
In response to Re: Insert performance for large transaction with multiple COPY FROM  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Insert performance for large transaction with multiple COPY FROM
List pgsql-performance
The types referenced by the foreign keys are the same Numeric(20).
Since the complete schema (of about 300 tables) is generated, I will just try char(20) instead of numeric(20) in the
nextdays to see if it makes any difference. Which I somehow doubt.  

But first I'm following the lead of the tables/indexes iostats given by Jeff.


obj_item_loc references the following three tables and there should be no surprises.

CREATE UNLOGGED TABLE loc
(
  loc_id numeric(20,0) NOT NULL,
...
  CONSTRAINT loc_pkey PRIMARY KEY (loc_id),
…
)

CREATE UNLOGGED TABLE obj_item
(
  obj_item_id numeric(20,0) NOT NULL,
...
  CONSTRAINT obj_item_pkey PRIMARY KEY (obj_item_id),
…
)

CREATE UNLOGGED TABLE rptd
(
  rptd_id numeric(20,0) NOT NULL,
...
  CONSTRAINT rptd_pkey PRIMARY KEY (rptd_id),
…
)


On 12.01.2013, at 23:18, Claudio Freire <klaussfreire@gmail.com> wrote:

> On Sat, Jan 12, 2013 at 5:16 PM, Horst Dehmer <horst.dehmer@gmail.com> wrote:
>> Yes, the ids is something I don't like either.
>> They carry additional semantics, which I cannot make go away.
>> How are chances char(20) is more time efficient than numeric(20)?
>> Disk space is no problem here.
>
> What are the other tables like then?
>
> The exact data types involved are at issue here, so it matters.



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Insert performance for large transaction with multiple COPY FROM
Next
From: Claudio Freire
Date:
Subject: Re: Insert performance for large transaction with multiple COPY FROM