From: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
---|---|
To: | "Keith Bottner" <kbottner(at)comcast(dot)net>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: What's faster? |
Date: | 2003-12-27 10:52:07 |
Message-ID: | 200312270552.07823.darcy@druid.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On December 26, 2003 07:11 pm, Keith Bottner wrote:
> I have a database where the vast majority of information that is related to
> a customer never changes. However, there is a single field (i.e. balance)
> that changes potentially tens to hundreds of times per day per customer
> (customers ranging in the 1000s to 10000s). This information is not
> indexed. Because Postgres requires VACUUM ANALYZE more frequently on
> updated tables, should I break this single field out into its own table,
> and if so what kind of a speed up can I expect to achieve. I would be
> appreciative of any guidance offered.
We went through this recently. One thing we found that may apply to you is
how many fields in the client record have a foreign key constraint. We find
that tables with lots of FKeys are a lot more intensive on updates. In our
case it was another table, think of it as an order or header table with a
balance, that has over 10 million records. Sometimes we have 200,000
transactions a day where we have to check the balance. We eventually moved
every field that could possibly be updated on a regular basis out to separate
tables. The improvement was dramatic.
--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-12-27 18:30:38 | Re: What's faster? |
Previous Message | Tom Lane | 2003-12-27 04:00:03 | Re: What's faster? |