On Sat, 22 Jan 2005 12:13:00 +0900 (JST), Tatsuo Ishii
[EMAIL PROTECTED] wrote:
IMO the bottle neck is not WAL but table/index bloat. Lots of updates
on large tables will produce lots of dead tuples. Problem is, There'
is no effective way to reuse these dead tuples since VACUUM on huge
tables
Dawid Kuroczko [EMAIL PROTECTED] writes:
Quick thought -- would it be to possible to implement a 'partial VACUUM'
per analogiam to partial indexes?
No.
But it gave me another idea. Perhaps equally infeasible, but I don't see why.
What if there were a map of modified pages. So every time any
On Sat, Jan 22, 2005 at 12:13:00 +0900,
Tatsuo Ishii [EMAIL PROTECTED] wrote:
Probably VACUUM works well for small to medium size tables, but not
for huge ones. I'm considering about to implement on the spot
salvaging dead tuples.
You are probably vacuuming too often. You want to wait
On Sat, 2005-01-22 at 12:41 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2005 at 12:13:00 +0900,
Tatsuo Ishii [EMAIL PROTECTED] wrote:
Probably VACUUM works well for small to medium size tables, but not
for huge ones. I'm considering about to implement on the spot
salvaging dead
From http://developer.postgresql.org/todo.php:
Maintain a map of recently-expired rows
This allows vacuum to reclaim free space without requiring a sequential
scan
On Sat, Jan 22, 2005 at 12:20:53PM -0500, Greg Stark wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
Quick thought -- would
Greg Stark [EMAIL PROTECTED] writes:
ken [EMAIL PROTECTED] writes:
From my understanding, all the data for these columns in all the child
tables will be stored in this one parent table
No, all the data is stored in the child table.
Correct ...
and that, furthermore, there is a hidden
Tatsuo Ishii [EMAIL PROTECTED] writes:
Probably VACUUM works well for small to medium size tables, but not
for huge ones. I'm considering about to implement on the spot
salvaging dead tuples.
That's impossible on its face, except for the special case where the
same transaction inserts and
Jim C. Nasby [EMAIL PROTECTED] writes:
(SELECT b.bucket_id AS rrs_bucket_id, s.*
FROM rrs.bucket b
JOIN page_log.log s
ON (
b.prev_end_time log_time
AND
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Hervé
Piedvache) transmitted:
Le Jeudi 20 Janvier 2005 15:24, Christopher Kings-Lynne a écrit :
Is there any solution with PostgreSQL matching these needs ... ?
You want: http://www.slony.info/
Do we have to backport
In the last exciting episode, [EMAIL PROTECTED] (Hervé Piedvache) wrote:
Le Jeudi 20 Janvier 2005 16:05, Joshua D. Drake a écrit :
Christopher Kings-Lynne wrote:
Or you could fork over hundreds of thousands of dollars for Oracle's
RAC.
No please do not talk about this again ... I'm
Quoth Ron Mayer [EMAIL PROTECTED]:
Merlin Moncure wrote:
...You need to build a bigger, faster box with lots of storage...
Clustering ... B: will cost you more, not less
Is this still true when you get to 5-way or 17-way systems?
My (somewhat outdated) impression is that up to about 4-way
After a long battle with technology, [EMAIL PROTECTED] (Hervé Piedvache), an
earthling, wrote:
Joshua,
Le Jeudi 20 Janvier 2005 15:44, Joshua D. Drake a écrit :
Hervé Piedvache wrote:
My company, which I actually represent, is a fervent user of PostgreSQL.
We used to make all our
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Greg Stark)
wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
Quick thought -- would it be to possible to implement a 'partial VACUUM'
per analogiam to partial indexes?
No.
But it gave me another idea. Perhaps equally
13 matches
Mail list logo