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
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
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 a
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 thi
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
"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
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 an
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
>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 -- w
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
> > salvagi
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 wa
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 a
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
> ta
13 matches
Mail list logo
