Re: [PERFORM] Query plan with missing timespans

Hello, At Wed, 22 Apr 2015 21:59:27 +0200, Andomar wrote in <5537fd9f.3060...@aule.net> > > Looping through 384 index scans of tbl, each taking 0.040 ms. > > That's 15.36 ms. That leaves 0.291 ms unaccounted for, which means > > that's about how much time the top level nested loop took to do it

Re: [PERFORM] Query plan with missing timespans

> On Apr 22, 2015, at 1:59 PM, Andomar wrote: > > Is there a way to tell postgres that a function will always return the same > result for the same parameter, within the same transaction? Yup… read over the Function Volatility Categories

Re: [PERFORM] Query plan with missing timespans

Looping through 384 index scans of tbl, each taking 0.040 ms. That's 15.36 ms. That leaves 0.291 ms unaccounted for, which means that's about how much time the top level nested loop took to do its work. Thanks for your reply, interesting! I'd have thought that this line actually implied 0 ms

Re: [PERFORM] Query plan with missing timespans

Andomar wrote: > In the output of "explain analyze" below, what was the query > doing between actual time 1.426 and 17.077? Looping through 384 index scans of tbl, each taking 0.040 ms. That's 15.36 ms. That leaves 0.291 ms unaccounted for, which means that's about how much time the top level n

[PERFORM] Query plan with missing timespans

This is a question about how to read "explain analyze". I've anonymized column names and table names. In the output of "explain analyze" below, what was the query doing between actual time 1.426 and 17.077? Kind regards, Andomar HashAggregate (cost=862.02..862.62 rows=48 width=90) (actua