Re: splitting up tables based on read/write frequency of columns

Hi

I'm pretty sure PostgreSQL can handle this.
But since you asked with a theoretic background,
it's probably worthwhile to look at column stores (like [1]).

-S.

[*] http://citusdata.github.io/cstore_fdw/

2015-01-19 22:47 GMT+01:00 Jonathan Vanasco <postgres@2xlp.com>:
> 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`,
withthe previous 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
intotheir own table? 
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general