Re: [HACKERS] EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads

On Tue, Oct 17, 2017 at 2:29 AM, Thomas Munro wrote: > Vik Fearing asked off-list why hash joins appear to read slightly more > temporary data than they write. The reason is that we notch up a > phantom block read when we hit the end of each file. Harmless but it

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

On Fri, Jul 8, 2016 at 12:55 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jul 7, 2016 at 10:07 AM, Tom Lane wrote: >>> Presumably the instrumentation data needed for that is not getting >>> returned from the worker to the

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

Robert Haas writes: > On Thu, Jul 7, 2016 at 10:07 AM, Tom Lane wrote: >> Presumably the instrumentation data needed for that is not getting >> returned from the worker to the leader. > Yes. > ... > I'm not sure about the rest of you, but I'd kind of

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

On Thu, Jul 7, 2016 at 10:07 AM, Tom Lane wrote: > Amit Kapila writes: >> On Thu, Jul 7, 2016 at 1:23 PM, Fujii Masao wrote: >>> I found $SUBJECT while trying to test parallel queries. Is this a bug? > > Presumably the

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

On Thu, Jul 7, 2016 at 7:37 PM, Tom Lane wrote: > Amit Kapila writes: >> On Thu, Jul 7, 2016 at 1:23 PM, Fujii Masao wrote: >>> I found $SUBJECT while trying to test parallel queries. Is this a bug? > > Presumably the

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

Amit Kapila writes: > On Thu, Jul 7, 2016 at 1:23 PM, Fujii Masao wrote: >> I found $SUBJECT while trying to test parallel queries. Is this a bug? Presumably the instrumentation data needed for that is not getting returned from the worker to the

Re: [HACKERS] EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.

On Thu, Jul 7, 2016 at 1:23 PM, Fujii Masao wrote: > Hi, > > I found $SUBJECT while trying to test parallel queries. Is this a bug? > > > In not parallel mode, EXPLAIN ANALYZE reports the information about > Sort Method as follows. > > =# EXPLAIN ANALYZE SELECT * FROM

Re: [HACKERS] explain analyze does not report actual rows correctly?

chang chao writes: > The actual rows(rows=9950) part in the following line contained in the above > query plan seems strange. > " -> Sort (cost=10.64..11.14 rows=200 width=520) (actual time=0.045..0.561 > rows=9950 loops=1)" > Shouldn't it be 200? No, that's probably

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Tue, Mar 15, 2016 at 5:22 AM, Robert Haas wrote: > > On Sat, Mar 12, 2016 at 1:58 AM, Amit Kapila wrote: > > Yeah, that makes the addition of test for this functionality difficult. > > Robert, do you have any idea what kind of test would have

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 1:58 AM, Amit Kapila wrote: > Yeah, that makes the addition of test for this functionality difficult. > Robert, do you have any idea what kind of test would have caught this issue? Yep. Committed with that test: DO $$ BEGIN EXECUTE

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 7:11 PM, Mithun Cy wrote: > > > > On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: > >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

Sorry there was some issue with my mail settings same mail got set more than once. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:02 PM, Mithun Cy wrote: > > > > On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila wrote > >I don't see how this test will fail with force_parallel_mode=regress and max_parallel_degree > 0 even without the patch proposed

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila wrote >I don't see how this test will fail with force_parallel_mode=regress and max_parallel_degree > 0 even without the patch proposed to fix the issue in >hand. In short, I don't think this test would have caught the issue,

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Fri, Mar 11, 2016 at 3:34 PM, Mithun Cy wrote: > > On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas wrote: > >I guess there must not be an occurrence of this pattern in the > >regression tests, or previous force_parallel_mode testing would have >

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas wrote: >I guess there must not be an occurrence of this pattern in the >regression tests, or previous force_parallel_mode testing would have >found this problem. Perhaps this patch should add one? I have added the test to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Thu, Mar 10, 2016 at 4:43 AM, Amit Kapila wrote: > There should be a white space between 0:CURSOR_OPT_PARALLEL_OK. Also I > don't see this comment is required as similar other usage doesn't have any > such comment. Fixed these two points in the attached patch. > > In

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Wed, Mar 9, 2016 at 8:18 PM, Mithun Cy wrote: > > Hi All, > > Explain [Analyze] Select Into table. produces the plan which uses parallel scans. > > Possible Fix: > > I tried to make a patch to fix this. Now in ExplainOneQuery if into clause is > > defined then

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

On 14/11/14 00:46, Simon Riggs wrote: Limit (cost= rows=20 width=175) (actual time= rows=20 loops=1) - Sort (cost= rows=568733 width=175) (actual time= rows=20 loops=1) Sort Method: top-N heapsort Going off on a tangent, when I was playing with a merge-sort

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

Jeremy Harris j...@wizmail.org writes: On 14/11/14 00:46, Simon Riggs wrote: Limit (cost= rows=20 width=175) (actual time= rows=20 loops=1) - Sort (cost= rows=568733 width=175) (actual time= rows=20 loops=1) Sort Method: top-N heapsort Going off on a tangent, when I was

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

On 14/11/14 14:54, Tom Lane wrote: Jeremy Harris j...@wizmail.org writes: On 14/11/14 00:46, Simon Riggs wrote: Limit (cost= rows=20 width=175) (actual time= rows=20 loops=1) - Sort (cost= rows=568733 width=175) (actual time= rows=20 loops=1) Sort Method: top-N heapsort

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

Simon Riggs si...@2ndquadrant.com writes: Limit (cost= rows=20 width=175) (actual time= rows=20 loops=1) - Sort (cost= rows=568733 width=175) (actual time= rows=20 loops=1) Sort Method: top-N heapsort The Sort estimate shows 568733 rows, whereas the actual rows

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

Tom Lane-2 wrote Simon Riggs lt; simon@ gt; writes: Limit (cost= rows=20 width=175) (actual time= rows=20 loops=1) - Sort (cost= rows=568733 width=175) (actual time= rows=20 loops=1) Sort Method: top-N heapsort The Sort estimate shows 568733 rows, whereas

Re: [HACKERS] EXPLAIN ANALYZE output weird for Top-N Sort

David G Johnston david.g.johns...@gmail.com writes: Tom Lane-2 wrote [ shrug... ] The estimated value is the planner's estimate of what would happen *if you ran the node to completion*, which in practice doesn't happen because of the LIMIT. I don't see how a sort node cannot run to

Re: [HACKERS] EXPLAIN (ANALYZE) broken

Kevin Grittner kgri...@ymail.com writes: Commit 2c92edad48796119c83d7dbe6c33425d1924626d has broken EXPLAIN's ANALYZE option in parentheses, which also makes some other options unusable. test=# EXPLAIN (ANALYZE) SELECT 1; ERROR:  syntax error at or near ANALYZE LINE 1: EXPLAIN (ANALYZE)

Re: [HACKERS] explain analyze query execution time

On 22/11/11 02:58, Kevin Grittner wrote: Rudyar wrote: I try to get the execution time of a query workload. I try using explain analyze but this time is allways higher than the execution time of a query across a client like pgadmin3 what is the reason about that difference? It's the

Re: [HACKERS] explain analyze query execution time

Rudyar wrote: what tool you recommend for measure the query real query execution time? The -hackers list is for discussion to coordinate development of the PostgreSQL database product. For user questions like this, please pick a more appropriate list based on the descriptions here:

Re: [HACKERS] explain analyze query execution time

On 22/11/11 10:26, Kevin Grittner wrote: Rudyar wrote: what tool you recommend for measure the query real query execution time? The -hackers list is for discussion to coordinate development of the PostgreSQL database product. For user questions like this, please pick a more appropriate

Re: [HACKERS] explain analyze query execution time

On 11/21/11, Rudyar rudyar.cor...@gmail.com wrote: Hello, I try to get the execution time of a query workload. I try using explain analyze but this time is allways higher than the execution time of a query across a client like pgadmin3 what is the reason about that difference? Analyze has

Re: [HACKERS] explain analyze query execution time

Rudyar wrote: I try to get the execution time of a query workload. I try using explain analyze but this time is allways higher than the execution time of a query across a client like pgadmin3 what is the reason about that difference? It's the observer effect -- there is a cost to the

Re: [HACKERS] Explain analyze getrusage tracking

On Mon, Nov 15, 2010 at 03:33, Greg Stark st...@mit.edu wrote: This is an update to my earlier patch to add getrusage resource tracking to EXPLAIN ANALYZE. With this patch you get something like:                                                  QUERY PLAN

Re: [HACKERS] Explain analyze getrusage tracking

On Mon, Nov 22, 2010 at 12:40 PM, Magnus Hagander mag...@hagander.net wrote: I tried building this under windows, and got a bunch of errors. Thanks! -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Explain analyze getrusage tracking

On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas robertmh...@gmail.com wrote: I don't really think these changes to the INSTR macros make much sense.  The macros don't really add much notational convenience; they're mostly wrappers to make the WIN32 and non-WIN32 cases work similarly for the

Re: [HACKERS] Explain analyze getrusage tracking

On Tue, Nov 16, 2010 at 12:19 PM, Greg Stark st...@mit.edu wrote: On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas robertmh...@gmail.com wrote: I don't really think these changes to the INSTR macros make much sense. The macros don't really add much notational convenience; they're mostly wrappers

Re: [HACKERS] Explain analyze getrusage tracking

On Tue, Nov 16, 2010 at 11:38 AM, Robert Haas robertmh...@gmail.com wrote: I think we should have a project policy of always printing memory and disk usage in kB, MB, GB etc unless they're functions returning an integer intended for machine use. rhaas=# set work_mem to '1048577kB';

Re: [HACKERS] Explain analyze getrusage tracking

On Tue, Nov 16, 2010 at 2:53 PM, Greg Stark st...@mit.edu wrote: Yeah, VERBOSE is kind of a catch-all for things that we don't have individual flags for.  But I think it's better for each piece of data to depend on one setting, rather than a combination of two or more settings.  Otherwise you

Re: [HACKERS] Explain analyze getrusage tracking

On Sun, Nov 14, 2010 at 9:33 PM, Greg Stark st...@mit.edu wrote: This is an update to my earlier patch to add getrusage resource tracking to EXPLAIN ANALYZE. With this patch you get something like:                                                  QUERY PLAN

Re: [HACKERS] explain analyze rows=%.0f

On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote: What I'd find strange about 6.67 rows in your example is more that on the estimated rows side, it seems to imply an unrealistically precise estimate in the same way that 667 rows would seem unrealistically precise to me. Maybe rounding to 2

Re: [HACKERS] explain analyze rows=%.0f

On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote: What I'd find strange about 6.67 rows in your example is more that on the estimated rows side, it seems to imply an unrealistically precise estimate in the same way

Re: [HACKERS] explain analyze rows=%.0f

Robert Haas robertmh...@gmail.com writes: On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@2ndquadrant.com wrote: You're right that the number of significant digits already exceeds the true accuracy of the computation. I think what Robert wants to see is the exact value used in the calc, so the

Re: [HACKERS] explain analyze rows=%.0f

...Robert On Jun 2, 2009, at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@2ndquadrant.com wrote: You're right that the number of significant digits already exceeds the true accuracy of the

Re: [HACKERS] explain analyze rows=%.0f

Euler Taveira de Oliveira wrote: Robert Haas escreveu: ...EXPLAIN ANALYZE reports the number of rows as an integer... Any chance we could reconsider this decision? I often find myself wanting to know the value that is here called ntuples, but rounding ntuples/nloops off to the nearest

Re: [HACKERS] explain analyze rows=%.0f

Joshua Tolley eggyk...@gmail.com writes: On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote: On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira Don't you think is too strange having, for example, 6.67 rows? No stranger than having it say 7 when it's really not. Actually

Re: [HACKERS] explain analyze rows=%.0f

On Fri, May 29, 2009 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: Joshua Tolley eggyk...@gmail.com writes: On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote: On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira Don't you think is too strange having, for example, 6.67 rows?

Re: [HACKERS] explain analyze rows=%.0f

Robert Haas escreveu: I have always assumed that there is some very good reason why EXPLAIN ANALYZE reports the number of rows as an integer rather than a floating point value, but in reading explain.c it seems that the reason is just that we decided to round to zero decimal places. Any

Re: [HACKERS] explain analyze rows=%.0f

On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira eu...@timbira.com wrote: Robert Haas escreveu: I have always assumed that there is some very good reason why EXPLAIN ANALYZE reports the number of rows as an integer rather than a floating point value, but in reading explain.c it

Re: [HACKERS] explain analyze rows=%.0f

On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote: On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira Don't you think is too strange having, for example, 6.67 rows? No stranger than having it say 7 when it's really not. Actually mine mostly come out 1 when the real value

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Greg, Gregory Stark wrote: I don't think DTrace is overkill either. The programmatic interface is undocumented (but I've gotten Sun people to admit it exists -- I just have to reverse engineer it from the existing code samples) but should be more or less exactly what we need. You probably

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Decibel! [EMAIL PROTECTED] writes: Also, has anyone looked into adding a class of system calls that would actually tell us if the kernel issued physical IO? I find it hard to believe that other RDBMSes wouldn't like to have that info... Yeah, I think that's called DTrace -- Gregory

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Decibel! [EMAIL PROTECTED] writes: When a read() call returns, surely the kernel knows whether it actually issued a physical read request to satisfy that. I don't see any reason why you couldn't have a version of read() that returns that information. I also rather doubt that we're the

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

On Dec 14, 2007, at 11:10 PM, Neil Conway wrote: But it occurred to me just now that the hardware instruction counter available on just about every platform would be good enough for a heuristic guess at whether the read(2) was cached. I'm skeptical that this would be reliable enough to be

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

On Mon, 17 Dec 2007, Decibel! wrote: Someone want to throw together some code that actually measures this? Maybe something that keeps a histogram of how many instructions take place per I/O request? If it turns out that counters do vary too much between CPUs, there might be ways that we can

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

On 12/17/07, Decibel! [EMAIL PROTECTED] wrote: Also, has anyone looked into adding a class of system calls that would actually tell us if the kernel issued physical IO? I find it hard to believe that other RDBMSes wouldn't like to have that info... Non-blocking style interfaces can help here.

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

On Dec 16, 2007 1:03 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote: Gokulakannan Somasundaram wrote: I was going to say that I'm really only interested in physical I/O. Logical I/O which is satisfied by the kernel cache is only marginally interesting and buffer fetches from Postgres's

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Gokulakannan Somasundaram [EMAIL PROTECTED] writes: Hi, I already made a discussion about it. We can view the Logical I/Os. If we enable the log_statement_stats in the conf file and apply the following patch, it is possible. But putting it in Explain analyze makes more sense to me. I

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

I was going to say that I'm really only interested in physical I/O. Logical I/O which is satisfied by the kernel cache is only marginally interesting and buffer fetches from Postgres's shared buffer is entirely uninteresting from the point of view of trying to figure out what is slowing down

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Gokulakannan Somasundaram wrote: I was going to say that I'm really only interested in physical I/O. Logical I/O which is satisfied by the kernel cache is only marginally interesting and buffer fetches from Postgres's shared buffer is entirely uninteresting from the point of view of trying to

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

On Fri, 2007-12-14 at 15:47 +, Gregory Stark wrote: I've wanted for a long time to have EXPLAIN ANALYZE output per-node I/O usage. This would be especially useful if we could distinguish hardware versus logical I/O though. And I always thought that would be very hard. My thought in the

Re: [HACKERS] EXPLAIN ANALYZE printing logical and hardware I/O per-node

Hi, I already made a discussion about it. We can view the Logical I/Os. If we enable the log_statement_stats in the conf file and apply the following patch, it is possible. But putting it in Explain analyze makes more sense to me. *** postgresql-8.3beta1/src/backend/storage/buffer/bufmgr.c

Re: [HACKERS] EXPLAIN ANALYZE

On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote: Simon Riggs wrote: Well, I'd like a way of making EXPLAIN ANALYZE return something useful within a reasonable amount of time. We can define that as the amount of time that the user considers is their goal for the query.

Re: [HACKERS] EXPLAIN ANALYZE

Thumbs up on this from a lurker. I recall a previous post about some sort of progress bar hack that would show you where in a plan a currently executing query was at. Has any work been done on this? Josh Reich Jim C. Nasby wrote: On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut

Re: [HACKERS] EXPLAIN ANALYZE

Richard Huxton wrote: Simon Riggs wrote: Intermediate results are always better than none at all. I do understand what a partial execution would look like - frequently it is the preparatory stages that slow a query down - costly sorts, underestimated hash joins etc. Other times it is loop

Re: [HACKERS] EXPLAIN ANALYZE

On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote: * Have EXPLAIN ANALYZE highlight poor optimizer estimates TODO updated: * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage I don't think this is

Re: [HACKERS] EXPLAIN ANALYZE

Neil Conway wrote: On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote: * Have EXPLAIN ANALYZE highlight poor optimizer estimates TODO updated: * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage

Re: [HACKERS] EXPLAIN ANALYZE

On Sun, 2006-12-10 at 18:09 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: The EA case is pretty straightforward though; Well, no its not, as you'll recall if you re-read the prior discussions. The killer problem is that it's unclear whether the early termination of the query

Re: [HACKERS] EXPLAIN ANALYZE

Tom Lane [EMAIL PROTECTED] writes: We might be able to finesse the protocol problem by teaching EA to respond to query cancel by emitting the data-so-far as a NOTICE (like it used to do many moons ago), rather than a standard query result, then allowing the query to error out. However

Re: [HACKERS] EXPLAIN ANALYZE

Simon Riggs wrote: Intermediate results are always better than none at all. I do understand what a partial execution would look like - frequently it is the preparatory stages that slow a query down - costly sorts, underestimated hash joins etc. Other times it is loop underestimation, which can

Re: [HACKERS] EXPLAIN ANALYZE

On Mon, 2006-12-11 at 11:00 +, Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: We might be able to finesse the protocol problem by teaching EA to respond to query cancel by emitting the data-so-far as a NOTICE (like it used to do many moons ago), rather than a standard query

Re: [HACKERS] EXPLAIN ANALYZE

Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2006-12-11 at 11:00 +, Gregory Stark wrote: What I suggested was introducing a new FE/BE message type for analyze query plans. I like the idea, but its more work than I really wanted to get into right now. Yeah ... a protocol change is

Re: [HACKERS] EXPLAIN ANALYZE

Tom Lane wrote: Yeah ... a protocol change is *painful*, especially if you really want clients to behave in a significantly new way. A backward-incompatible protocol change is painful, sure, but ISTM we could implement what Greg describes as a straightforward extension to the V3 protocol.

Re: [HACKERS] EXPLAIN ANALYZE

Simon Riggs wrote: I like the idea, but its more work than I really wanted to get into right now. Well, from another point of view: do we need this feature so urgently that there is not enough time to do it properly? IMHO, no. -Neil ---(end of

Re: [HACKERS] EXPLAIN ANALYZE

Neil Conway [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah ... a protocol change is *painful*, especially if you really want clients to behave in a significantly new way. A backward-incompatible protocol change is painful, sure, but ISTM we could implement what Greg describes as a

Re: [HACKERS] Explain Analyze mode

See your postgresql.conf for log_planner_stats = true #false log_executor_stats = true #false #log_statement_stats = false Oleg On Fri, 11 Mar 2005, Ioannis Theoharis wrote: Hi, i found this form of output of explain analyze, watching some old mails in lists. test4=# explain analyze select *