Re: Insert performance

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Insert performance
Date: 2003-08-19 06:33:26
Message-ID: 3F42120E.28901.E71BBDF@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 19 Aug 2003 at 1:16, Hannu Krosing wrote:

> Shridhar Daithankar kirjutas E, 18.08.2003 kell 19:02:
> > I was loading a geographic data couple of months back.. It was 3GB data when
> > loaded in postgresql.
>
> With or without indexes ?

Without index. Index was another 3 GB with 50% utilisation. It was 81M rows
with 3 floats each..

>
> > I tried loading data first and creating index later. It ran out of available
> > 9GB space. So I created index on an empty table and started loading it. It was
> > slow but at least finished after 3 hours... Co-incidentally oracle had same
> > problems as well. So creating index beforehand remains only option at times, it
> > seems. Tom remarked that it shouldn't have made difference but apparently it
> > does..
>
> Tom just fixed some memory leaks on array indexing the other day. Could
> there be something like that on geographic types ?

Dunno.. This was 7.3.2 or earlier.. Later the project abandoned all types of
databases and went to in memory structures since flat data was of the order of
200MB. Now they aer returning to databases as flat data is approaching excess
of 3 GB..

God knows what will they do next. It's an ideal example what schedule pressure
can do to architecture design of a software..

Bye
Shridhar

--
Air Force Inertia Axiom: Consistency is always easier to defend than correctness.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message alvis 2003-08-20 10:01:16 When NOT to index small tables?
Previous Message Shridhar Daithankar 2003-08-19 06:28:45 Re: Insert performance