Search Postgresql Archives

splitting up tables based on read/write frequency of columns

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is really a theoretical/anecdotal question, as I'm not at a scale yet where this would measurable.  I want to investigate while 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 the 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 into their own table?




-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux