On Wed, 2007-08-15 at 12:49 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we can do something to reduce the xid consumption? For example,
reuse xids for read-only queries.
Hmm, that's an idea.
That would be a very useful idea for additional scalability and it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford to
Added to TODO:
* Reduce XID consumption of read-only queries
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00516.php
---
Florian G. Pflug wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On Thu, Aug 16, 2007 at 04:13:55PM +0200, Florian G. Pflug wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
I was talking to someone at LinuxWorld and they mentioned they often
have activity of 6k SELECTs per second, and that they were needing to
autovacuum every few days because of xid wraparound.
I did some calculations and found that:
6000 * 60 * 60 * 24
51840
or 500
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford to
vacuum every couple
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford
Bruce Momjian wrote:
Is enlarging the xid field something we should consider for 8.4? Is the
autovacuum I/O less then the extra I/O needed for an expanded xid fields
on every row?
I doubt that's going to happen...
Maybe we can do something to reduce the xid consumption? For example,
reuse
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we can do something to reduce the xid consumption? For example,
reuse xids for read-only queries.
Hmm, that's an idea.
More simply, just keep the current transaction open (resetting
everything but the XID) if we have made no changes by the
On Wed, Aug 15, 2007 at 12:49:52PM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we can do something to reduce the xid consumption? For example,
reuse xids for read-only queries.
Hmm, that's an idea.
More simply, just keep the current transaction open
Decibel! [EMAIL PROTECTED] writes:
Aren't there potential issues with keeping the same XID if a transaction
in the middle has modified data?
I don't see any, as long as you take a new snapshot.
Something else to think about... any app that's doing that kind of
transaction rate is likely
On Wednesday 15 August 2007 09:49:52 Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we can do something to reduce the xid consumption? For example,
reuse xids for read-only queries.
Hmm, that's an idea.
More simply, just keep the current transaction open (resetting
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
regards, tom lane
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with pgbench -c 150 -t 2 -s
Heikki Linnakangas írta:
Zoltan Boszormenyi wrote:
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with pgbench
Zoltan Boszormenyi wrote:
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with pgbench -c 150 -t 2 -s 200
in about _ten
Zoltan Boszormenyi wrote:
used a real disk, the secondary used tmpfs as PGDATA. Say whatever you want
about my disk lying about flush, its 75MB/sec transfer rate transfer
rate is real.
So 5 million real transaction in 24 hours is not unrealistic.
6k xacts / s is five *hundred*
On Wednesday 15 August 2007 13:54, Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
Aren't there potential issues with keeping the same XID if a transaction
in the middle has modified data?
I don't see any, as long as you take a new snapshot.
I'm a little confused, wouldnt the
Robert Treat [EMAIL PROTECTED] writes:
I'm a little confused, wouldnt the transaction that waits 30 minutes before
modifying data need to get an XID that jives with the system when it's
transaction started, not when it began manipulating data?
Why?
Would it really be safe to take a new
On Wed, Aug 15, 2007 at 5:06 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm a little confused, wouldnt the transaction that waits 30 minutes before
modifying data need to get an XID that jives with the system when it's
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
You wouldn't take a new snapshot. The thought that occurs to me is that
there's no reason that a transaction has to have an XID for itself
before it takes a snapshot. We always special-case our own XID anyway.
I'm
21 matches
Mail list logo
