Heikki Linnakangas írta:
Hans-Juergen Schoenig wrote:
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for visibility
reasons).
so, from time to time it happens that i exceed my CommandCounter (>
2.000.000.000 statements inside the same transaction).
Interesting. What kind of a stored procedure is that?
One optimization that might be possible is to not increment it for
statements that do on-disk changes.
my idea is: how about adding a configure option to compile postgres with
a 64 bit command counter. this would allow larger transactions for
special purpose applications while it would not have an impact on normal
applications.
One objection to expanding TransactionId to 64-bits has been that we
depend on assignment of TransactionId to be atomic. That might not be an
issue with CommandIds; I don't think we store commandids in shared
memory structures. It still doesn't feel like a good idea to me, though.
Isn't 64-bit assignment atomic on 64-bit machines?
With a little autoconf magic, the conditional can be
disabled for 32-bit platforms. So that's not a real obstacle
for going to 64-bit TransactionIds.
--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
