pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedEXPLAIN
21+ messages / 15 participants
[nested] [flat]
* EXPLAIN
@ 1999-02-03 23:00 Andy <alewis@mpsi.net>
1999-02-03 23:11 ` Re: [GENERAL] EXPLAIN Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 21+ messages in thread
From: Andy @ 1999-02-03 23:00 UTC (permalink / raw)
To: pgsql-general
When I do an explain what does the cost, size and width mean that is returned?
Seq Scan on apts (cost=249.95 size=2362 width=468)
Thanks
Andy
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] EXPLAIN
1999-02-03 23:00 EXPLAIN Andy <alewis@mpsi.net>
@ 1999-02-03 23:11 ` Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 21+ messages in thread
From: Bruce Momjian @ 1999-02-03 23:11 UTC (permalink / raw)
To: alewis@mpsi.net; +Cc: pgsql-general
> When I do an explain what does the cost, size and width mean that is returned?
>
> Seq Scan on apts (cost=249.95 size=2362 width=468)
Cost is a computed value by the optimizer of how long it will execute.
It is meaningful only in comparison to there queries. size if the
number of rows estimated to return. width is the number of bytes per
row returned.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 21+ messages in thread
* EXPLAIN
@ 1999-07-05 13:18 Ansley, Michael <Michael.Ansley@intec.co.za>
0 siblings, 0 replies; 21+ messages in thread
From: Ansley, Michael @ 1999-07-05 13:18 UTC (permalink / raw)
To: pgsql-general; 'pgsql-admin@postgresql.org' <pgsql-admin@postgresql.org>
Is there any way that the result of an EXPLAIN can be put into a table, say
each line going into a new row, or something?
MikeA
^ permalink raw reply [nested|flat] 21+ messages in thread
* EXPLAIN
@ 1999-10-29 01:12 John Henderson <jrh@is.com.fj>
0 siblings, 0 replies; 21+ messages in thread
From: John Henderson @ 1999-10-29 01:12 UTC (permalink / raw)
To: pgsql-general@hub.org
Hi folks,
Where can i find some notes on how to interpret a query plan as generated by
EXPLAIN? This seems like a useful tool especially for a beginner like me but
I need some tips on using it :)
Here is an example:
isfiji=> explain select u.custid, u.username,
isfiji-> u.realname, u.level, u.address, u.contact, u.phone, u.fax,
u.circuit,
isfiji-> u.email, t.town,
isfiji-> p.profession, u.silent, u.startdate, a.area, u.notes, u.services,
isfiji-> u.active, u.passwd, u.suspended, u.disconnected,u.h_phone,
u.rec_date,
isfiji-> u.con_date, u.susp_date, u.disc_date from userdir u,
isfiji-> area a,
isfiji-> profession p, town t where u.towncode=t.town_id and
u.profcode=p.prof_id
isfiji-> and a.area_id=t.area_id and
isfiji-> upper(circuit)~~'1480495'
isfiji-> order by u.realname;
NOTICE: QUERY PLAN:
Sort (cost=2.63 size=0 width=0)
-> Nested Loop (cost=2.63 size=2 width=260)
-> Nested Loop (cost=1.53 size=1 width=246)
-> Nested Loop (cost=0.00 size=1 width=220)
-> Seq Scan on profession p (cost=0.00 size=0
width=14)
-> Seq Scan on userdir u (cost=269.06 size=364
width=206)
-> Seq Scan on town t (cost=1.53 size=16 width=26)
-> Seq Scan on area a (cost=1.10 size=3 width=14)
EXPLAIN
Example questions:
How is total cost calculated? Is the cost of an inner Loop or sub query
added to or multiplied by the enclosing loop? What should I be looking out
for? etc. etc.
Thanks for your time,
John Henderson
^ permalink raw reply [nested|flat] 21+ messages in thread
* Explain
@ 2001-01-05 09:18 Jeff Davis <jdavis@wasabimg.com>
2001-01-05 09:25 ` Re: Explain Heiko Irrgang <irrgang@SC-Networks.de>
2001-01-05 16:43 ` Re: Explain Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 21+ messages in thread
From: Jeff Davis @ 2001-01-05 09:18 UTC (permalink / raw)
To: pgsql-general
How can I conveniently handle output from an EXPLAIN query inside an
application? It appears to just immediately send the output to the stdout of
whatever program uses it. Is there a way to get the output inside a program,
with libpq or otherwise? I would actually like to be able to get the output in
a PHP script, but getting it in any application would be nice.
Thanks,
Jeff Davis
--
Jeff Davis
jdavis@dynworks.com
http://dynworks.com
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Explain
2001-01-05 09:18 Explain Jeff Davis <jdavis@wasabimg.com>
@ 2001-01-05 09:25 ` Heiko Irrgang <irrgang@SC-Networks.de>
1 sibling, 0 replies; 21+ messages in thread
From: Heiko Irrgang @ 2001-01-05 09:25 UTC (permalink / raw)
To: pgsql-general
>How can I conveniently handle output from an EXPLAIN query inside an
>application? It appears to just immediately send the output to the stdout of
>whatever program uses it. Is there a way to get the output inside a program,
>with libpq or otherwise? I would actually like to be able to get the output in
>a PHP script, but getting it in any application would be nice.
AFAIK it dont works directly, but you can do the following:
<?php
$f=popen("psql -U username -c 'explain select * from table' -d dbname
2>/dev/stdout","r");
while($nextline=fgets($f,4096)) {
echo($nextline."<br>");
}
pclose($f);
?>
this would dump the explain-result as you get it in psql as html-text.
with popen("command","r") you open a stream to the command and
because psql seems to send
the result of explain to stderr you have to redirect it to stdout
(2>/dev/stdout)
then you can handle the filedescriptor delivered by popen() as a normal file
with fgets(), but you have to close it with pclose() not fclose().
this works exactly the same within a c program but i dont know much
about programming postgres in c. it may be possible to have the
same result directly with libpq, but for php this seems to be
the only way to do this.
--
SC-Networks www: www.SC-Networks.de
Web Design, Netzwerke,
3D Animation und Multimedia
Heiko Irrgang Tel.: 08856/9392-00
Im Thal 2 Fax: 08856/9392-01
82377 Penzberg Mail: Irrgang@SC-Networks.de
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Explain
2001-01-05 09:18 Explain Jeff Davis <jdavis@wasabimg.com>
@ 2001-01-05 16:43 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 21+ messages in thread
From: Tom Lane @ 2001-01-05 16:43 UTC (permalink / raw)
To: Jeff Davis <jdavis@wasabimg.com>; +Cc: pgsql-general
Jeff Davis <jdavis@wasabimg.com> writes:
> How can I conveniently handle output from an EXPLAIN query inside an
> application? It appears to just immediately send the output to the stdout of
> whatever program uses it. Is there a way to get the output inside a program,
> with libpq or otherwise?
The EXPLAIN result is sent as a NOTICE message, so you can trap it by
setting libpq's notice processor function --- see PQsetNoticeProcessor.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* explain ?
@ 2003-04-18 13:19 Patrick Welche <prlw1@newn.cam.ac.uk>
2003-04-18 14:20 ` Re: explain ? Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 21+ messages in thread
From: Patrick Welche @ 2003-04-18 13:19 UTC (permalink / raw)
To: pgsql-general
I had a query which was dog slow. Explain showed the following:
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Aggregate (cost=7878.67..7878.67 rows=1 width=24)
-> Nested Loop (cost=0.00..7878.66 rows=1 width=24)
-> Seq Scan on trans (cost=0.00..7875.63 rows=1 width=20)
Filter: ((firsttimei = 2) AND (sourcepeeraddress = '192.168.0.1'::inet) AND (flowindex = 2))
-> Index Scan using stats_pkey on stats (cost=0.00..3.02 rows=1 width=4)
Index Cond: (stats.id = "outer".stats_id)
Filter: (timeslice < 'Thu 13 Mar 00:00:00 2003'::timestamp without time zone)
(7 rows)
I created an index on firsttimei, vacuum full analysed, and explain showed me
*exactly* the same thing(!) The difference being that the query is now
lightning fast :-) So, what is explain actually telling me? The diffence
is the Filter: returns true|false more quickly because of the index?
Cheers,
Patrick
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain ?
2003-04-18 13:19 explain ? Patrick Welche <prlw1@newn.cam.ac.uk>
@ 2003-04-18 14:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-19 23:18 ` Re: explain ? Patrick Welche <prlw1@newn.cam.ac.uk>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2003-04-18 14:20 UTC (permalink / raw)
To: Patrick Welche <prlw1@newn.cam.ac.uk>; +Cc: pgsql-general
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> I created an index on firsttimei, vacuum full analysed, and explain showed me
> *exactly* the same thing(!) The difference being that the query is now
> lightning fast :-)
Perhaps the vacuum got rid of a whole bunch of dead rows?
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain ?
2003-04-18 13:19 explain ? Patrick Welche <prlw1@newn.cam.ac.uk>
2003-04-18 14:20 ` Re: explain ? Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-04-19 23:18 ` Patrick Welche <prlw1@newn.cam.ac.uk>
0 siblings, 0 replies; 21+ messages in thread
From: Patrick Welche @ 2003-04-19 23:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Patrick Welche <prlw1@newn.cam.ac.uk>; pgsql-general
On Fri, Apr 18, 2003 at 10:20:33AM -0400, Tom Lane wrote:
> Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> > I created an index on firsttimei, vacuum full analysed, and explain showed me
> > *exactly* the same thing(!) The difference being that the query is now
> > lightning fast :-)
>
> Perhaps the vacuum got rid of a whole bunch of dead rows?
I had done a vacuum full earlier.. and by dog slow versus lightning
fast, I mean 1 unit of data inserted in just over an hour versus
8.6 units of data inserted in 2 mins 29 seconds(!) Well, I'm
certainly not complaining!
Cheers,
Patrick
^ permalink raw reply [nested|flat] 21+ messages in thread
* explain
@ 2009-01-07 16:30 Gustavo Rosso <grosso@sadaic.org.ar>
2009-01-07 15:53 ` Re: explain hubert depesz lubaczewski <depesz@depesz.com>
2009-01-07 15:54 ` Re: explain Jaime Casanova <jcasanov@systemguards.com.ec>
0 siblings, 2 replies; 21+ messages in thread
From: Gustavo Rosso @ 2009-01-07 16:30 UTC (permalink / raw)
To: pgsql-general
Es 1.213ms un valor correcto para realizar un insert en una tabla
obtenido por explain analyze.
Gustavo
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2009-01-07 16:30 explain Gustavo Rosso <grosso@sadaic.org.ar>
@ 2009-01-07 15:53 ` hubert depesz lubaczewski <depesz@depesz.com>
2009-01-07 15:55 ` Re: explain Jaime Casanova <jcasanov@systemguards.com.ec>
1 sibling, 1 reply; 21+ messages in thread
From: hubert depesz lubaczewski @ 2009-01-07 15:53 UTC (permalink / raw)
To: Gustavo Rosso <grosso@sadaic.org.ar>; +Cc: pgsql-general
On Wed, Jan 07, 2009 at 01:30:54PM -0300, Gustavo Rosso wrote:
> Es 1.213ms un valor correcto para realizar un insert en una tabla
> obtenido por explain analyze.
trochę długo, ale to zależy od sprzętu. dodatkowo - może masz tam
triggery? klucze obce? ciężko powiedzieć. pokaż schemat tabeli i tego
inserta to coś więcej będziemy mogli powiedzieć.
depesz
p.s. as you can clearly see from another mails from this list - the list
uses english language. please use it, or if you'd like to use spanish
(i'm not sure if your language if spanish, i don't know it) - you can
use list pgsql-es-ayuda
(http://archives.postgresql.org/pgsql-es-ayuda/).
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2009-01-07 16:30 explain Gustavo Rosso <grosso@sadaic.org.ar>
2009-01-07 15:53 ` Re: explain hubert depesz lubaczewski <depesz@depesz.com>
@ 2009-01-07 15:55 ` Jaime Casanova <jcasanov@systemguards.com.ec>
2009-01-07 16:38 ` Re: [GENERAL] explain Emanuel Calvo Franco <postgres.arg@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Jaime Casanova @ 2009-01-07 15:55 UTC (permalink / raw)
To: depesz@depesz.com; +Cc: Gustavo Rosso <grosso@sadaic.org.ar>; pgsql-general
On Wed, Jan 7, 2009 at 10:53 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
>
> p.s. as you can clearly see from another mails from this list - the list
> uses english language. please use it, or if you'd like to use spanish
> (i'm not sure if your language if spanish, i don't know it) - you can
> use list pgsql-es-ayuda
> (http://archives.postgresql.org/pgsql-es-ayuda/).
>
oops! i answered in spanish too! i never saw the list it was sent to...
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [GENERAL] explain
2009-01-07 16:30 explain Gustavo Rosso <grosso@sadaic.org.ar>
2009-01-07 15:53 ` Re: explain hubert depesz lubaczewski <depesz@depesz.com>
2009-01-07 15:55 ` Re: explain Jaime Casanova <jcasanov@systemguards.com.ec>
@ 2009-01-07 16:38 ` Emanuel Calvo Franco <postgres.arg@gmail.com>
0 siblings, 0 replies; 21+ messages in thread
From: Emanuel Calvo Franco @ 2009-01-07 16:38 UTC (permalink / raw)
To: pgsql-es-ayuda <pgsql-es-ayuda@postgresql.org>
Gustavo, pega el resultado del explain y el insert.
tambien informa siempre la versión exacta de Pgsql y el tamaño de la base.
Si vez que no ha nada raro, pega un 'iostat' si estas en SO *nix
2009/1/7 Jaime Casanova <jcasanov@systemguards.com.ec>:
> On Wed, Jan 7, 2009 at 10:53 AM, hubert depesz lubaczewski
> <depesz@depesz.com> wrote:
>>
>> p.s. as you can clearly see from another mails from this list - the list
>> uses english language. please use it, or if you'd like to use spanish
>> (i'm not sure if your language if spanish, i don't know it) - you can
>> use list pgsql-es-ayuda
>> (http://archives.postgresql.org/pgsql-es-ayuda/).
>>
>
> oops! i answered in spanish too! i never saw the list it was sent to...
>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Emanuel Calvo Franco
Syscope Postgresql Consultant
ArPUG / AOSUG Member
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2009-01-07 16:30 explain Gustavo Rosso <grosso@sadaic.org.ar>
@ 2009-01-07 15:54 ` Jaime Casanova <jcasanov@systemguards.com.ec>
1 sibling, 0 replies; 21+ messages in thread
From: Jaime Casanova @ 2009-01-07 15:54 UTC (permalink / raw)
To: Gustavo Rosso <grosso@sadaic.org.ar>; +Cc: pgsql-general
2009/1/7 Gustavo Rosso <grosso@sadaic.org.ar>:
> Es 1.213ms un valor correcto para realizar un insert en una tabla obtenido
> por explain analyze.
eso es un poco mas de un milisegundo, no parece mucho... en todo caso
el tiempo que demore un INSERT dependera en parte de la cantidad de
indices, FK y triggers que tenga una tabla
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
^ permalink raw reply [nested|flat] 21+ messages in thread
* explain
@ 2025-04-24 13:31 Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Marc Millas @ 2025-04-24 13:31 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
hello,
there is something I seem missing in explain analyze buffers results when
track_io_timing is on:
this is the first lines of an explain: (the request is of no interest, such
a result is quite frequent)
Nested Loop Left Join (cost=941400.77..966327.57 rows=3 width=653) (actual
time=52655.694..62533.811 rows=346 loops=1)
Buffers: shared hit=10068265 read=396705 dirtied=1858 written=218, temp
read=429687 written=115187
I/O Timings: read=79368.246 write=11.486
So, the total execution time is 52655 ms ok
and the total time for i/o is...79368 ms
how ???
thanks
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
@ 2025-04-24 13:41 ` David Rowley <dgrowleyml@gmail.com>
2025-04-24 13:51 ` Re: explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 15:06 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 2 replies; 21+ messages in thread
From: David Rowley @ 2025-04-24 13:41 UTC (permalink / raw)
To: Marc Millas <marc.millas@mokadb.com>; +Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
On Fri, 25 Apr 2025 at 01:32, Marc Millas <marc.millas@mokadb.com> wrote:
> Nested Loop Left Join (cost=941400.77..966327.57 rows=3 width=653) (actual time=52655.694..62533.811 rows=346 loops=1)
> Buffers: shared hit=10068265 read=396705 dirtied=1858 written=218, temp read=429687 written=115187
> I/O Timings: read=79368.246 write=11.486
>
> So, the total execution time is 52655 ms ok
> and the total time for i/o is...79368 ms
>
> how ???
The 79.3 seconds is the total time spent doing reads for all parallel
workers. 52.6 seconds is the wall clock time elapsed to execute the
query.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
@ 2025-04-24 13:51 ` Marc Millas <marc.millas@mokadb.com>
1 sibling, 0 replies; 21+ messages in thread
From: Marc Millas @ 2025-04-24 13:51 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Thanks !
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Thu, Apr 24, 2025 at 3:41 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Fri, 25 Apr 2025 at 01:32, Marc Millas <marc.millas@mokadb.com> wrote:
> > Nested Loop Left Join (cost=941400.77..966327.57 rows=3 width=653)
> (actual time=52655.694..62533.811 rows=346 loops=1)
> > Buffers: shared hit=10068265 read=396705 dirtied=1858 written=218,
> temp read=429687 written=115187
> > I/O Timings: read=79368.246 write=11.486
> >
> > So, the total execution time is 52655 ms ok
> > and the total time for i/o is...79368 ms
> >
> > how ???
>
> The 79.3 seconds is the total time spent doing reads for all parallel
> workers. 52.6 seconds is the wall clock time elapsed to execute the
> query.
>
> David
>
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
@ 2025-04-24 15:06 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-04-25 00:36 ` Re: explain David Rowley <dgrowleyml@gmail.com>
1 sibling, 1 reply; 21+ messages in thread
From: Laurenz Albe @ 2025-04-24 15:06 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; Marc Millas <marc.millas@mokadb.com>; +Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
On Fri, 2025-04-25 at 01:41 +1200, David Rowley wrote:
> On Fri, 25 Apr 2025 at 01:32, Marc Millas <marc.millas@mokadb.com> wrote:
> > Nested Loop Left Join (cost=941400.77..966327.57 rows=3 width=653) (actual time=52655.694..62533.811 rows=346 loops=1)
> > Buffers: shared hit=10068265 read=396705 dirtied=1858 written=218, temp read=429687 written=115187
> > I/O Timings: read=79368.246 write=11.486
> >
> > So, the total execution time is 52655 ms ok
> > and the total time for i/o is...79368 ms
> >
> > how ???
>
> The 79.3 seconds is the total time spent doing reads for all parallel
> workers. 52.6 seconds is the wall clock time elapsed to execute the
> query.
But wouldn't it read "loops=3" or similar then?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
2025-04-24 15:06 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
@ 2025-04-25 00:36 ` David Rowley <dgrowleyml@gmail.com>
2025-04-25 06:02 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-04-25 00:36 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Marc Millas <marc.millas@mokadb.com>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
On Fri, 25 Apr 2025 at 03:06, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Fri, 2025-04-25 at 01:41 +1200, David Rowley wrote:
> > The 79.3 seconds is the total time spent doing reads for all parallel
> > workers. 52.6 seconds is the wall clock time elapsed to execute the
> > query.
>
> But wouldn't it read "loops=3" or similar then?
Only if the Nested Loop was below the Gather / Gather Merge node.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: explain
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
2025-04-24 15:06 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
2025-04-25 00:36 ` Re: explain David Rowley <dgrowleyml@gmail.com>
@ 2025-04-25 06:02 ` Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 21+ messages in thread
From: Laurenz Albe @ 2025-04-25 06:02 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Marc Millas <marc.millas@mokadb.com>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
On Fri, 2025-04-25 at 12:36 +1200, David Rowley wrote:
> On Fri, 25 Apr 2025 at 03:06, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> > On Fri, 2025-04-25 at 01:41 +1200, David Rowley wrote:
> > > The 79.3 seconds is the total time spent doing reads for all parallel
> > > workers. 52.6 seconds is the wall clock time elapsed to execute the
> > > query.
> >
> > But wouldn't it read "loops=3" or similar then?
>
> Only if the Nested Loop was below the Gather / Gather Merge node.
Ah, I see. The I/O time accrued in a different, lower, parallelized step
of the execution plan.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2025-04-25 06:02 UTC | newest]
Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-02-03 23:00 EXPLAIN Andy <alewis@mpsi.net>
1999-02-03 23:11 ` Bruce Momjian <maillist@candle.pha.pa.us>
1999-07-05 13:18 EXPLAIN Ansley, Michael <Michael.Ansley@intec.co.za>
1999-10-29 01:12 EXPLAIN John Henderson <jrh@is.com.fj>
2001-01-05 09:18 Explain Jeff Davis <jdavis@wasabimg.com>
2001-01-05 09:25 ` Re: Explain Heiko Irrgang <irrgang@SC-Networks.de>
2001-01-05 16:43 ` Re: Explain Tom Lane <tgl@sss.pgh.pa.us>
2003-04-18 13:19 explain ? Patrick Welche <prlw1@newn.cam.ac.uk>
2003-04-18 14:20 ` Re: explain ? Tom Lane <tgl@sss.pgh.pa.us>
2003-04-19 23:18 ` Re: explain ? Patrick Welche <prlw1@newn.cam.ac.uk>
2009-01-07 16:30 explain Gustavo Rosso <grosso@sadaic.org.ar>
2009-01-07 15:53 ` Re: explain hubert depesz lubaczewski <depesz@depesz.com>
2009-01-07 15:55 ` Re: explain Jaime Casanova <jcasanov@systemguards.com.ec>
2009-01-07 16:38 ` Re: [GENERAL] explain Emanuel Calvo Franco <postgres.arg@gmail.com>
2009-01-07 15:54 ` Re: explain Jaime Casanova <jcasanov@systemguards.com.ec>
2025-04-24 13:31 explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 13:41 ` Re: explain David Rowley <dgrowleyml@gmail.com>
2025-04-24 13:51 ` Re: explain Marc Millas <marc.millas@mokadb.com>
2025-04-24 15:06 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
2025-04-25 00:36 ` Re: explain David Rowley <dgrowleyml@gmail.com>
2025-04-25 06:02 ` Re: explain Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox