Re: [GENERAL] slow, long-running 'commit prepared'

2008-12-01 Thread Tom Lane
"John Smith" <[EMAIL PROTECTED]> writes: > The transaction where COMMIT PREPARED was slow basically did the > following 20 times: > - create a child table T1 as select from another child table T2 > - drops child table T2 > - renames T1 to T2 > What here would cause the 2PC state file to grow la

Re: [GENERAL] slow, long-running 'commit prepared'

2008-12-01 Thread John Smith
The transaction where COMMIT PREPARED was slow basically did the following 20 times: - create a child table T1 as select from another child table T2 - drops child table T2 - renames T1 to T2 What here would cause the 2PC state file to grow large? In my rough experiments, its size seems constant

Re: [GENERAL] slow, long-running 'commit prepared'

2008-11-26 Thread Tom Lane
"John Smith" <[EMAIL PROTECTED]> writes: > I have a pg instance with 700GB of data, almost all of which is in one > table. When I PREPARE and then COMMIT PREPARED a transaction that > reads & writes to a large fraction of that data (about 10%, > effectively randomly chosen rows and so every file in

Re: [GENERAL] slow, long-running 'commit prepared'

2008-11-25 Thread Andrew Sullivan
On Tue, Nov 25, 2008 at 08:05:36PM -0800, John Smith wrote: > Thanks for the quick response, Andrew. How could the 'commit prepared' > be I/O bound? Isn't all the I/O accomplished during 'prepare > transaction', leaving only a tiny bit of data to write at commit? No. When you do PREPARE TRANSACTI

Re: [GENERAL] slow, long-running 'commit prepared'

2008-11-25 Thread John Smith
Thanks for the quick response, Andrew. How could the 'commit prepared' be I/O bound? Isn't all the I/O accomplished during 'prepare transaction', leaving only a tiny bit of data to write at commit? > > You could be I/O bound. Have a look at iostat and sar. > > A > -- > Andrew Sullivan > ajs(at)cr

Re: [GENERAL] slow, long-running 'commit prepared'

2008-11-25 Thread Andrew Sullivan
On Tue, Nov 25, 2008 at 07:17:20PM -0800, John Smith wrote: > I have a pg instance with 700GB of data, almost all of which is in one > table. When I PREPARE and then COMMIT PREPARED a transaction that > reads & writes to a large fraction of that data (about 10%, > effectively randomly chosen rows a

[GENERAL] slow, long-running 'commit prepared'

2008-11-25 Thread John Smith
I have a pg instance with 700GB of data, almost all of which is in one table. When I PREPARE and then COMMIT PREPARED a transaction that reads & writes to a large fraction of that data (about 10%, effectively randomly chosen rows and so every file in the table is modified), the COMMIT PREPARED some