[ADMIN] List of Functions Reference
Does anyone have a reference that includes all of the functions like date_part that shows the usages etc eg what it will accept in what place etc etc Timothy Hitchens (Hitcho) Web Evangelist/Technologist Voice: +61 7 3396 3500 Fax: +61 7 3396 2633 Cell: +61 419 521 440 SMS: [EMAIL PROTECTED] (subject only) E-Mail: [EMAIL PROTECTED] URL: http://www.hitcho.com.au/ - "Everyone is born into this world with two things freewill and potential what we do from then on is totally up to us. Let's all start today and make a difference in this world." -
Re: [ADMIN] v7.1b4 bad performance
Michael Ansley [EMAIL PROTECTED] writes: I would consider this perfectly acceptable. Official benchmarks can only be without the -F switch prior to 7.1, so in raw performance terms (with acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F, because those are the fastest configurations with acceptable recovery. How's that again? 7.1 with -F is just as much at the mercy of a system crash as previous releases with -F, because it's not fsync'ing the WAL log. In either case, -F is only for those who trust their hardware + OS + UPS, or perhaps are running development systems and care more for speed than data recoverability. However, I would also expect 7.0.2 -F to be faster than 7.1beta4 -F, because 7.1beta4 is doing more (WAL specifically). Over the same plans, the engine is doing more work, so must be slower. No, because 7.1 is able to batch writes to data files over multiple transactions, given enough buffer space (larger -B makes more difference than it used to). That buys back some or all of the performance lost to WAL logfile writes. See Tatsuo's curves, and the similar numbers posted by myself and Peter Schmidt. On that one benchmark, at least, 7.1 is not slower, even with -F. (Given zero commit_delay, anyway ;-)) regards, tom lane
RE: [ADMIN] v7.1b4 bad performance
Title: RE: [ADMIN] v7.1b4 bad performance I thought that -F only turned off the shared mem fsyncing. Obviously not. I'll rethink my analysis ;-) -Original Message- From: Tom Lane To: Michael Ansley Cc: 'Schmidt, Peter '; ''Bruce Momjian' '; ''[EMAIL PROTECTED]' ' Sent: 2-17-01 4:13 PM Subject: Re: [ADMIN] v7.1b4 bad performance Michael Ansley [EMAIL PROTECTED] writes: I would consider this perfectly acceptable. Official benchmarks can only be without the -F switch prior to 7.1, so in raw performance terms (with acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F, because those are the fastest configurations with acceptable recovery. How's that again? 7.1 with -F is just as much at the mercy of a system crash as previous releases with -F, because it's not fsync'ing the WAL log. In either case, -F is only for those who trust their hardware + OS + UPS, or perhaps are running development systems and care more for speed than data recoverability. However, I would also expect 7.0.2 -F to be faster than 7.1beta4 -F, because 7.1beta4 is doing more (WAL specifically). Over the same plans, the engine is doing more work, so must be slower. No, because 7.1 is able to batch writes to data files over multiple transactions, given enough buffer space (larger -B makes more difference than it used to). That buys back some or all of the performance lost to WAL logfile writes. See Tatsuo's curves, and the similar numbers posted by myself and Peter Schmidt. On that one benchmark, at least, 7.1 is not slower, even with -F. (Given zero commit_delay, anyway ;-)) regards, tom lane ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify Nick West - Global Infrastructure Manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
[ADMIN] How to monitor postmaster to find a trouble query?
Hi, I am running a productive server of postgresql 7.03, but sometimes it have a high load average value more than 10, it must be caused by a trouble query, although I have carefully checked my queries, I still can not find which query made this. I wish there is a way to monitor the query, for example, when I use 'top' find a postgres process take more than 50% CPU, I can check which query is executed in it. I have tried add query=4 in pq_options file, but nothing recorded in syslog.
Re: [ADMIN] How to monitor postmaster to find a trouble query?
"lt" [EMAIL PROTECTED] writes: I have tried add query=4 in pq_options file, but nothing recorded in syslog. Are you starting the postmaster with -S ? That suppresses its log... regards, tom lane
