On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific to this patch:
While it's good to do most testing with debug and
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I thought that output of new counters are too wide and it brakes
compatibility of EXPLAIN ANALYZE. On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4. However, overheads should be
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
Welcome to psql 8.2.9, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
Robert Haas [EMAIL PROTECTED] writes:
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
The current behaviour is newly added in 8.4. In 8.2 it meant something
completely different and quite
Robert Haas [EMAIL PROTECTED] writes:
On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4.
Uh, it exists for me in 8.2.9.
EXPLAIN VERBOSE has existed at least back to 7.0, probably further.
However, we've felt free to whack
As stuff matures and becomes indispensable we could consider moving it to the
regular EXPLAIN or implement some way to specify precisely which data the user
wants. Or just say XML/table data/whatever will solve the problem for us.
I think some way to specify precisely which data the user wants
I'm not sure what the best way is though. I don't think continuing to
add keywords between EXPLAIN and the start of the query is very
scalable. Putting parentheses around the option list seems like it
might eliminate a lot of grammar headaches:
Do you think it is required to invent special
On Tue, Dec 9, 2008 at 01:20, Greg Smith [EMAIL PROTECTED] wrote:
On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific to
On Mon, Dec 8, 2008 at 23:28, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] wrote:
I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation.
Yes this is one reasonable option, as is the idea of using XML or a
table and making it the client's problem. Neither are going to happen
for this release I think.
And in any case it will always be useful to have an option to print
all the available information anyways so we make as well
On Tue, Dec 9, 2008 at 8:53 PM, Robert Haas [EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 12:44 PM, Greg Stark [EMAIL PROTECTED]
wrote:
Yes this is one reasonable option, as is the idea of using XML or a table
and making it the client's problem. Neither are going to happen for this
On Tue, Dec 9, 2008 at 12:44 PM, Greg Stark [EMAIL PROTECTED] wrote:
Yes this is one reasonable option, as is the idea of using XML or a table
and making it the client's problem. Neither are going to happen for this
release I think.
Agreed.
And in any case it will always be useful to have an
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
... Some other things I accidentally left out.
Tom Lane [EMAIL PROTECTED] wrote:
Please split this into two separate patches that can be separately
evaluated.
Sure. I want to disucuss only where to add counters of buffer usage
and cpu usage, or they should not be added. However, it seems to
affect future of EXPLAIN ANALYZE, so we might
Alex Hunsaker [EMAIL PROTECTED] wrote:
#define GUCNAME(name) (statistics. name)
Why statistics?
Would not something like stat_statements make more sense? Statistics
seems fairly arbitrary...
Not to use duplicated statements words;
variable names contains statements already.
-
Alex Hunsaker [EMAIL PROTECTED] wrote:
I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation.
(buffer usage and CPU usage)
- Should EXPLAIN ANALYZE show those counters.
Vladimir Sitnikov [EMAIL PROTECTED] wrote:
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
I do not get the point of VERBOSE.
As far as I understand, explain analyze (without verbose) will anyway add
overhead for calculation of gets/hits/cpu. Why discard that
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
I do not get the point of VERBOSE.
As far as I understand, explain analyze (without verbose) will anyway add
overhead for calculation of gets/hits/cpu. Why discard that information
in
non verbose mode? Just to
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
Submission review:
Is the patch in standard form? Yes
Does it apply cleanly to current HEAD? Yes (with fuzz)
Does it
On Fri, 5 Dec 2008, Vladimir Sitnikov wrote:
Oracle's approach is to have the explain command stuff the results into a
table. That has advantages for tools, especially if you want to be able to
look at plans generated by other sessions.
I do not believe that workflow makes sense. I have never
The main benefit is that you can track how EXPLAIN plans change over time.
It is not required to output plan *into* some table to be able track it over
time. If EXPLAIN returns a table, it is up to you to perform insert into
history select * from explain(...).
Workflow that does not make sense
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
I do not get the point of VERBOSE.
As far as I understand, explain analyze (without verbose) will anyway add
overhead for calculation of gets/hits/cpu. Why discard that information in
non verbose mode? Just to make the
Vladimir Sitnikov [EMAIL PROTECTED] writes:
I wish there was a way to get the results of explain into some table. I wish
it was the default output format. That would make life of pgAdmin easier,
and improve readability even in psql. Do not you think there is something
wrong with having
Vladimir Sitnikov [EMAIL PROTECTED] writes:
I wish there was a way to get the results of explain into some table. I
wish
it was the default output format. That would make life of pgAdmin
easier,
and improve readability even in psql. Do not you think there is something
wrong with
Here is an update version of contrib/pg_stat_statements.
New modifications from the last version are:
1. New counters in struct Instrumentation.
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
3. Buffer statistics counsters are not reset to zero anymore.
1. New
25 matches
Mail list logo
