From: | Aaron Turner <synfinatic(at)gmail(dot)com> |
---|---|
To: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: large dataset with write vs read clients |
Date: | 2010-10-07 20:03:47 |
Message-ID: | AANLkTinrHCpS0QqDDMhpyTXyc5xB_XbtsZ+WceN2qm+G@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Oct 7, 2010 at 12:02 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Aaron Turner (synfinatic(at)gmail(dot)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"
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-07 20:31:36 | Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance |
Previous Message | Greg Stark | 2010-10-07 19:35:10 | Re: On Scalability |