Tom Lane t...@sss.pgh.pa.us writes:
2. I'm unconvinced by the proposed changes to accumulate backend-local
I/O counters, too. The fact of the matter is that those counters are
left over from Berkeley days, a time when PG hackers tended to do their
performance measurements in standalone
I wrote:
I'm not enamored of saved_file either, it seems like the wrong
part of speech somehow. Maybe save_in_file?
Actually ... what is the point of letting users control the filename at
all? It seems like the only useful nondefault value is the empty string
(to suppress storing the stats).
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is an updated version of contrib/pg_stat_statements patch.
I've committed this with significant revisions. Other than the points
already mentioned in previous messages:
* I removed the proposed changes to the behavior of the core
Thank you for many works.
Tom Lane t...@sss.pgh.pa.us wrote:
1. The proposed change to track system/user CPU time presents an
enormous cost, and no argument has been made to show that there is any
comparable benefit.
2. I'm unconvinced by the proposed changes to accumulate backend-local
On Fri, Jan 2, 2009 at 20:20, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* the startup/shutdown hooks will be installed in the postmaster
process, but the patch expects them to be executed in a child process.
I think nothing will happen.
OK, I figured out what is happening there: the patch
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Alex Hunsaker bada...@gmail.com wrote:
How about just pg_stat_statements.track ?
I renamed the variables to:
- pg_stat_statements.limit
- pg_stat_statements.track
- pg_stat_statements.saved_file
Hmm, this has got a
I wrote:
* the startup/shutdown hooks will be installed in the postmaster
process, but the patch expects them to be executed in a child process.
I think nothing will happen.
OK, I figured out what is happening there: the patch makes it work by
means of this expedient:
diff -cprN
Alex Hunsaker bada...@gmail.com writes:
... So Im going to mark it as
ready for commmiter.
Has this patch been tested on Windows? (Or more generally, with EXEC_BACKEND?)
The reason I ask is that eyeballing the code suggests a couple of major
problems in that area:
* the startup/shutdown
On Thu, Jan 1, 2009 at 17:28, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
... So Im going to mark it as
ready for commmiter.
Has this patch been tested on Windows? (Or more generally, with
EXEC_BACKEND?)
I was under the impression thats where Itagaki-san
I wrote:
* in an EXEC_BACKEND situation, we re-execute
process_shared_preload_libraries() when starting a fresh backend
(but not in other kinds of child processes, which is why the other
problem is a problem). This means re-executing the _PG_init function,
which will try to redefine the
On Thu, Jan 1, 2009 at 19:59, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* in an EXEC_BACKEND situation, we re-execute
process_shared_preload_libraries() when starting a fresh backend
(but not in other kinds of child processes, which is why the other
problem is a problem). This means
On Mon, Dec 29, 2008 at 15:46, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
look (you did fix the race/not protected by a spinlock you found
earlier
Here is an updated version of contrib/pg_stat_statements patch.
Alex Hunsaker bada...@gmail.com wrote:
I think the explain_analyze_format guc is a clever way of getting
around the explain analyze verbose you proposed earlier. But I dont
see any doc updates for it.
Documentation is added.
14 matches
Mail list logo
