How about counting the number of dead tuples examined and the number of live
tuples returned. As the ratio of dead tuples over live tuples visited
increases the table becomes a candidate for vacuuming.
-regards
richt
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECT
> -Original Message-
> From: Dhruv Pilania [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 20, 2002 11:37 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: PITR and rollback
>
>
> Hi,
>
> I am a new postgresql developer. needed some help with wal/PITR. Ca
oint me to your source online,
that would be good too.
I just want to clarify though: is this work released to the PostgreSQL
Development group by Progress and Multera, or do they still claim
copyright interest in it?
Regards,
J.R. Nield
On Thu, 2002-07-18 at 12:56, Richard Tu
I don't know how our marketing came up third most popular but I think the
order is, Oracle, MySQL, and PostgreSQL or maybe Oracle, MSSQL and
PostgreSQL. I'm sure there is some criterion by which PostgreSQL is tenth
and by some other its number one.
Of course, my posting was about Point In Time Re
BA to protect the database from media loss just needs to set the
wal_file_duplicate paramater and periodically pg_copy the database.
The BIG THING we have not done is address the issue that add/drop tables and
indexes do not propagate through the roll forward recovery mechanism
properly.
-reg
While it is true that you can't do binary searches on compressed indexes you
may get a large payoff with compressed indexes since the index fits in fewer
pages and so may be more efficiently cached in the buffer pool. Even a
small reduction in io load may compensate for the higher computational
d
