[PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Dawid Kuroczko
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Greg Stark
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Bruno Wolff III
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Rod Taylor
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Jim C. Nasby
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

Re: [PERFORM] inheritance performance

2005-01-22 Thread Tom Lane
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Tom Lane
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

Re: [PERFORM] Odd number of rows expected

2005-01-22 Thread Tom Lane
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Christopher Browne
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Christopher Browne
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Christopher Browne
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

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-22 Thread Christopher Browne
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

[PERFORM] Cheaper VACUUMing

2005-01-22 Thread Christopher Browne
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