| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Kevin Brown" <kevin(at)sysexperts(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: stats_command_string default? |
| Date: | 2003-02-17 01:32:04 |
| Message-ID: | 005601c2d624$60658d70$6500a8c0@fhp.internal |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
> Averaging over three trials on an unloaded system, I got 21.0 seconds
> with stats_command_string off, 27.7 with it on, or about 32% overhead.
>
> My conclusion is that stats_command_string overhead is non-negligible
> for simple commands. So I stand by my previous opinion that it should
> not be turned on without the DBA taking explicit action to turn it on.
> Do you want it on in every future benchmark, for example?
How about with the stats_collector on? ie. Recording block and row level
stats?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2003-02-17 01:51:54 | Hard problem with concurrency |
| Previous Message | Ross J. Reedstrom | 2003-02-17 00:23:34 | Re: psql and readline |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-02-17 02:30:06 | Re: stats_command_string default? |
| Previous Message | Tom Lane | 2003-02-16 20:55:57 | Re: stats_command_string default? |