203 reputation
128
bio website
location
age
visits member for 2 years, 5 months
seen Apr 9 at 8:08

Nov
20
awarded  Famous Question
Oct
9
awarded  Popular Question
Aug
14
awarded  Popular Question
Jul
25
awarded  Yearling
Jun
8
awarded  Nice Question
Mar
12
comment Sharding Postgres Database
Our problem isn't the customer table as that's fairly small, which is hundreds. The problem is that each customer has a whole host of other tables, and these can be fairly large. See the note about each table in my database being foreign keyed on the customer table.
Mar
12
asked Sharding Postgres Database
May
21
awarded  Notable Question
Jan
10
awarded  Popular Question
Jul
26
comment PostgreSQL Initial Database Size
Interesting stuff, I'll have a read of it and try to get a better understanding of what HOT updates mean to my system.
Jul
24
comment Aggressive Autovacuum on PostgreSQL
This is due to locking of the summary tables, as these are locked using SHARE ROW EXCLUSIVE MODE. Concurrent writes without the lock may succeed, but they are most certainly going to end up with wrong values. Imagine I'm maintaining a count N of rows of type X. If I concurrently insert 2 rows of type X, without locking I will end up with N + 1 in my summary table instead of N + 2. The solution I've adopted is to have a cron job that manually vacuums the summary tables in my database. It works well and seems to be the recommended approach, but it feels too much like a hack to me.
Jul
18
revised Aggressive Autovacuum on PostgreSQL
added 235 characters in body
Jul
18
asked Aggressive Autovacuum on PostgreSQL
Jul
18
awarded  Scholar
Jul
18
accepted PostgreSQL Initial Database Size
Jul
18
awarded  Editor
Jul
18
revised PostgreSQL Initial Database Size
Updated for posterity.
Jul
18
awarded  Supporter
Jul
17
awarded  Student
Jul
17
asked PostgreSQL Initial Database Size