Re: [PERFORM] Help with count(*)
On Fri, 14 Nov 2003, Tom Lane wrote: I believe the previous discussion also agreed that we wanted to postpone the freezing of now(), which currently also happens at BEGIN rather than the first command after BEGIN. Or should that happen at the first call to now()? /me should ge back and try to find this previous discussion. -- /Dennis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] INSERT extremely slow with large data sets (fwd)
--- Slavisa Garic [EMAIL PROTECTED] wrote: Does VACUUM ANALYZE help with the analysis or it also speeds up the process. I know i could try that before I ask but experiment is running now and I am too curious to wait :), Anyway thanks for the hint, Slavisa VACUUM ANALYZE will reclaim disk space and update statistics used by the optimizer to help execute queries faster. This could speed up your inserts. See http://www.postgresql.org/docs/7.3/static/sql-vacuum.html. George Essig ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Error in transaction processing
When I execute a transaction using embedded sql statements in a c program, I get the error, Error in transaction processing. I could see from the documentation that it means, Postgres signalled to us that we cannot start, commit or rollback the transaction I don't find any mistakes in the transaction statements. What can I do to correct this error? Your response would be very much appreciated. Thanks and Regards, Radha ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Help with count(*)
Tom Lane [EMAIL PROTECTED] writes: (I believe the previous discussion also agreed that we wanted to postpone the freezing of now(), which currently also happens at BEGIN rather than the first command after BEGIN.) That doesn't make sense to me: from a user's perspective, the start of the transaction is when the BEGIN is issued, regardless of any tricks we may play in the backend. Making now() return the time the current transaction started is reasonably logical; making now() return the time when the first command after the BEGIN in the current transaction was issued makes a lot less sense to me. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
