Hi,
We turned on autovacuums on 8.2 and we have a database which is read
only , it is basically a USPS database used only for address lookups
(only SELECTS, no updates/deletes/inserts).
This database has about 10gig data and yesterday autovacuum started
on this database and all of a
Pallav Kalva [EMAIL PROTECTED] writes:
We turned on autovacuums on 8.2 and we have a database which is read
only , it is basically a USPS database used only for address lookups
(only SELECTS, no updates/deletes/inserts).
This database has about 10gig data and yesterday autovacuum
Tom Lane wrote:
Pallav Kalva [EMAIL PROTECTED] writes:
We turned on autovacuums on 8.2 and we have a database which is read
only , it is basically a USPS database used only for address lookups
(only SELECTS, no updates/deletes/inserts).
This database has about 10gig data
Alvaro Herrera wrote:
Pallav Kalva wrote:
Tom Lane wrote:
Probably represents freezing of old tuples, which is a WAL-logged
operation as of 8.2. Is it likely that the data is 200M transactions
old?
If nothing changed on these tables how can it freeze old tuples ?
Does
Pallav Kalva wrote:
Tom Lane wrote:
Probably represents freezing of old tuples, which is a WAL-logged
operation as of 8.2. Is it likely that the data is 200M transactions
old?
If nothing changed on these tables how can it freeze old tuples ?
Does it mean that once it reaches 200M
On Fri, 2007-08-31 at 12:25 -0400, Pallav Kalva wrote:
Can you please correct me if I am wrong, I want to understand how this
works.
Based on what you said, it will run autovacuum again when it passes 200M
transactions, as SELECTS are transactions too and are going on these
tables.
But
[EMAIL PROTECTED] (Pallav Kalva) writes:
Tom Lane wrote:
Pallav Kalva [EMAIL PROTECTED] writes:
We turned on autovacuums on 8.2 and we have a database which is
read only , it is basically a USPS database used only for address
lookups (only SELECTS, no updates/deletes/inserts).
On 8/31/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Pallav Kalva wrote:
Tom Lane wrote:
Probably represents freezing of old tuples, which is a WAL-logged
operation as of 8.2. Is it likely that the data is 200M transactions
old?
If nothing changed on these tables how can it freeze
Mark Lewis wrote:
On Fri, 2007-08-31 at 12:25 -0400, Pallav Kalva wrote:
Can you please correct me if I am wrong, I want to understand how this
works.
Based on what you said, it will run autovacuum again when it passes 200M
transactions, as SELECTS are transactions too and are going on
Mikko Partio escribió:
Off-topic question: the documentation says that XID numbers are 32 bit.
Could the XID be 64 bit when running on a 64 bit platform? That would
effectively prevent wrap-around issues.
No, because they would take too much space in tuple headers.
--
Alvaro Herrera
Pallav Kalva wrote:
My main concern is filling up my disk with archive logs, so from all the
replies I get is that since tuples are already frozen, next time when it
runs autovacuum it wont generate any archive logs.
Is my assumption right ?
Well, it won't generate any logs for the tuples
Alvaro Herrera [EMAIL PROTECTED] writes:
Mikko Partio escribió:
Off-topic question: the documentation says that XID numbers are 32 bit.
Could the XID be 64 bit when running on a 64 bit platform? That would
effectively prevent wrap-around issues.
No, because they would take too much space in
On Aug 31, 2007, at 2:08 PM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Mikko Partio escribió:
Off-topic question: the documentation says that XID numbers are
32 bit.
Could the XID be 64 bit when running on a 64 bit platform? That
would
effectively prevent wrap-around
Erik Jones [EMAIL PROTECTED] writes:
On Aug 31, 2007, at 2:08 PM, Tom Lane wrote:
It's worth noting that the patch Florian is working on, to suppress
assignment of XIDs for transactions that never write anything, will make
for a large reduction in the rate of XID consumption in many real-world
[EMAIL PROTECTED] (Pallav Kalva) writes:
Mark Lewis wrote:
On Fri, 2007-08-31 at 12:25 -0400, Pallav Kalva wrote:
Can you please correct me if I am wrong, I want to understand how
this works.
Based on what you said, it will run autovacuum again when it passes
200M transactions, as SELECTS
On Fri, 31 Aug 2007, Tom Lane wrote:
If he gets it done soon (before the HOT dust settles) I will be strongly
tempted to try to sneak it into 8.3 ...
Could you or Florian suggest how other people might assist in meeting that
goal? It seems like something worthwhile but it's not clear to me
I wrote:
Mark Lewis [EMAIL PROTECTED] writes:
We've been holding back from upgrading to 8.2 because this one is a
show-stopper for us.
Well, you could always make your own version with this patch reverted:
http://archives.postgresql.org/pgsql-committers/2006-11/msg00066.php
I might end up
Greg Smith [EMAIL PROTECTED] writes:
On Fri, 31 Aug 2007, Tom Lane wrote:
If he gets it done soon (before the HOT dust settles) I will be strongly
tempted to try to sneak it into 8.3 ...
Could you or Florian suggest how other people might assist in meeting that
goal? It seems like
On Fri, 2007-08-31 at 19:39 -0400, Tom Lane wrote:
I wrote:
Mark Lewis [EMAIL PROTECTED] writes:
We've been holding back from upgrading to 8.2 because this one is a
show-stopper for us.
Well, you could always make your own version with this patch reverted:
Hi,
I was looking for opinions on performance for a design involving schemas. We
have a 3-tier system with a lot of hand-written SQL in our Java-based server,
but we want to start limiting the data that different users can access based on
certain user properties. Rather than update hundreds
Hi,
I was looking for opinions on performance for a design involving schemas. We
have a 3-tier system with a lot of hand-written SQL in our Java-based server,
but we want to start limiting the data that different users can access based on
certain user properties. Rather than update hundreds
Hi,
I was looking for opinions on performance for a design involving schemas. We
have a 3-tier system with a lot of hand-written SQL in our Java-based server,
but we want to start limiting the data that different users can access based on
certain user properties. Rather than update hundreds
22 matches
Mail list logo
