Re: large dataset with write vs read clients - Mailing list pgsql-performance

From Aaron Turner
Subject Re: large dataset with write vs read clients
Date
Msg-id AANLkTinrHCpS0QqDDMhpyTXyc5xB_XbtsZ+WceN2qm+G@mail.gmail.com
Whole thread Raw
In response to Re: large dataset with write vs read clients  (Stephen Frost <sfrost@snowman.net>)
List pgsql-performance
On Thu, Oct 7, 2010 at 12:02 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Aaron Turner (synfinatic@gmail.com) wrote:
>> Basically, each connection is taking about 100MB resident
>
> Errr..  Given that your shared buffers are around 100M, I think you're
> confusing what you see in top with reality.  The shared buffers are
> visible in every process, but it's all the same actual memory, not 100M
> per process.

Ah, I had missed that.  Thanks for the tip.  Sounds like I should
still investigate pgpool though.  If nothing else it should improve
insert performance right?

As for the tables, no indexes.  We're using a constraint on one of the
columns (date) w/ table inheritance to limit which tables are scanned
since SELECT's are always for a specific date range.  By always
querying the inherited table, we're effectively getting a cheap
semi-granular index without any insert overhead.  Unfortunately,
without forking the RTG code significantly, redesigning the schema
really isn't viable.

--
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
"carpe diem quam minimum credula postero"

pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: large dataset with write vs read clients
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance