Tom,
Shouldn't it be possible to build vacuum as an ongoing internal PG process,
instead of a seperate operation? How does Oracle byepass this? Must be some
way that can be implemented.
Any pointers to further reading to brush up my theory in this regard please?
IAC, regarding the actual inquiry, wouldn't be a replicated database on a
second server be more cheaper than Oracle, if the party is satisfied with
PG performance? I browsed some PG commercial organization site that told
about a Replication Server being available for PG. I am about to look into
that next month. Is it any good like PG? Will provide failover too..rather
than using Oracle.
With best regards.
Sanjay.
At 05:53 PM 1/23/01 , Tom Lane wrote:
>Thomas.Favier@accelance.fr writes:
>> - Is 2 minutes a standard time for vacuuming a 500.000 rows table ?
>> - Can it be reduced ?
>> - In a far future, what are the problems we can run into not vacuuming
>> that table ? We have already seen that after a month, some transactions
>> involving where id >= some_value take forever, so we supressed them.
>
>If it takes a month before query performance gets bad, then perhaps you
>could vacuum the table only once a month. However, that vacuum would
>probably take longer than two minutes, so it's a tradeoff...
>
>We have plans for 7.2 to reduce the need for periodic vacuums, but that
>won't help you much now.
>
>There are patches available for a "lazy vacuum" process on 7.0.3,
>which can be a win if vacuum only needs to get rid of a few rows.
>But they're not very thoroughly tested IMHO. See
>http://people.freebsd.org/~alfred/vacfix/
>
> regards, tom lane
>
