Re: [PERFORM] Function scan/Index scan to nested loop

2010-05-25 Thread Robert Haas
On Tue, May 11, 2010 at 2:00 PM, Carlo Stonebanks wrote: > I am concerned that there is such a lag between all the index and function > scans start/complete times and and the nested loops starting. I have > reformatted the SLOW PLAN results below to make them easier to read. Can you > tell me if t

Re: [PERFORM] Function scan/Index scan to nested loop

2010-05-11 Thread Carlo Stonebanks
Thanks Scott, This is almost always due to caching. First time the data aren't in the cache, second time they are. << I had assumed that it was caching, but I don't know from where because of the inexplicable delay. Hardware? O/S (Linux)? DB? From the function, which is IMMUTABLE? I am co

Re: [PERFORM] Function scan/Index scan to nested loop

2010-05-11 Thread Craig Ringer
On 11/05/10 13:32, Carlo Stonebanks wrote: > Hello all, > > A query ran twice in succession performs VERY poorly the first time as > it iterates through the nested loop. The second time, it rips. Please > see SQL, SLOW PLAN and FAST PLAN below. I haven't looked at the details, but the comment you

Re: [PERFORM] Function scan/Index scan to nested loop

2010-05-11 Thread Scott Marlowe
On Mon, May 10, 2010 at 11:32 PM, Carlo Stonebanks wrote: > Hello all, > > A query ran twice in succession performs VERY poorly the first time as it > iterates through the nested loop. The second time, it rips. Please see SQL, > SLOW PLAN and FAST PLAN below. This is almost always due to caching.

[PERFORM] Function scan/Index scan to nested loop

2010-05-10 Thread Carlo Stonebanks
Hello all, A query ran twice in succession performs VERY poorly the first time as it iterates through the nested loop. The second time, it rips. Please see SQL, SLOW PLAN and FAST PLAN below. I don't know why these nested loops are taking so long to execute. " -> Nested Loop (cost=0.00..42