splitting up tables based on read/write frequency of columns - Mailing list pgsql-general

From Jonathan Vanasco
Subject splitting up tables based on read/write frequency of columns
Date
Msg-id E6BFE6DF-C8A4-4886-A72A-1779ADD150A8@2xlp.com
Whole thread Raw
Responses Re: splitting up tables based on read/write frequency of columns
Re: splitting up tables based on read/write frequency of columns
List pgsql-general
This is really a theoretical/anecdotal question, as I'm not at a scale yet where this would measurable.  I want to
investigatewhile this is fresh in my mind... 

I recall reading that unless a row has columns that are TOASTed, an `UPDATE` is essentially an `INSERT + DELETE`, with
theprevious row marked for vacuuming. 

A few of my tables have the following characteristics:
    - The Primary Key has many other tables/columns that FKEY onto it.
    - Many columns (30+) of small data size
    - Most columns (90%) are 1 WRITE(UPDATE) for 1000 READS
    - Some columns (10%) do a bit of internal bookkeeping and are 1 WRITE(UPDATE) for 50 READS

Has anyone done testing/benchmarking on potential efficiency/savings by consolidating the frequent UPDATE columns into
theirown table? 




pgsql-general by date:

Previous
From: Robert DiFalco
Date:
Subject: Re: asynchronous commit
Next
From: Robert DiFalco
Date:
Subject: Re: Simple Atomic Relationship Insert