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] Postgresql Host Swapping Hard With Abundant Free Memory

On 4/17/15 1:25 PM, Christian Gough wrote: Here are our competing theories of why we are swapping as much as 10-15GB with 6GB-10GB of free memory: How are you determining that you're swapping? How are you measuring 'free memory'? 1.) maintenance_work_mem and work_mem are set too high causing

[PERFORM] Postgresql Host Swapping Hard With Abundant Free Memory

Greetings, We have been having some pretty painful site outages related to heavy swapping, even though the system may appear to have as much as 10GB of free memory. It seems that as soon as the system hits ~22GB (of 32GB) of memory usage it starts to swap. As soon as we go below ~22GB, swap is

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

Re: [PERFORM] extract(year from date) doesn't use index but maybe could?

On 4/19/15 4:33 PM, Tom Lane wrote: We might still be willing to do it if there were a sufficiently wide range of examples that could be handled by the same extra machinery, but this doesn't look too promising from that angle: AFAICS only the "year" case could yield a useful index restriction.