| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 2 years |
| seen | 2 days ago | |
| stats | profile views | 3 |
A ghost in the machine.
|
2d |
awarded | Caucus |
|
2d |
awarded | Constituent |
|
Oct 19 |
comment |
Alter table on live production databases Note: the "correct way" specificified is relative to MySQL and not to PostgreSQL. The "correct way" in PostgreSQL is typically very easy, though it can be involved. Use of pg_reorg can help with the more difficult scenarios. |
|
Oct 19 |
comment |
Alter table on live production databases The key thing in what @Craig said was, "if it oesn't require re-writing." Using an ALTER TABLE t ADD COLUMN i INT is a fast operation (typically <1ms) once the lock is acquired. Acquiring the lock can queue up connections, however, so it's not "free" ... though it's world's better than what you have to do in MySQL. Adding a NOT NULL constraint is more difficult and not for the feignt of heart. |
|
Jun 21 |
comment |
Degrading PostgreSQL 8.4 write performance Last thoughts, if you don't have any FOREIGN KEYs, do you have any INDEXes on the TABLE? Any TABLE inheritance? Is autovacuum running? Is there anything special about your file system? |
|
Jun 21 |
comment |
Degrading PostgreSQL 8.4 write performance @OlegT, there are zero constraints on the PostgreSQL side of things in this regard. If the total size of rows are >1K in size, I'd start to throw out a few ideas. At 64 bytes, there should be no problems. BYTEA is a fundamental storage blob that most data types "inherit" from (or as close as you can in C using the VARLENA structure). Can you SELECT * FROM pg_catalog.pg_locks during an UPDATE? A yet-to-be-disclosed something is the culprit. This problem seems very specific to your environment and I'd suggest you jump in to the #PostgreSQL channel for further debugging and discussion. |
|
Jun 18 |
awarded | Teacher |
|
Jun 17 |
answered | Degrading PostgreSQL 8.4 write performance |
|
Jun 1 |
comment |
How to insert an IP-address into an inet column in PostgreSQL? Cast your text value to ::INET. '192.168.1.083'::INET should be sufficient. |
|
Jun 1 |
comment |
How fast should I expect to load data on a high performance computer? Absolutely. synchronous_commit = off is the preferred & recommended way of getting the speed benefits of fsync = off without sacrificing the integrity of your database. |
|
May 31 |
answered | How fast should I expect to load data on a high performance computer? |
|
May 26 |
awarded | Supporter |