Re: [PERFORM] printing results of query to file in different times - Mailing list pgsql-performance

From George Neuner
Subject Re: [PERFORM] printing results of query to file in different times
Date
Msg-id ccea0e2f-641b-ac78-5b0a-b1eb7f8b8a4e@comcast.net
Whole thread Raw
In response to Re: [PERFORM] printing results of query to file in different times  (George Neuner <gneuner2@comcast.net>)
List pgsql-performance
Hi Mariel,

On 9/6/2017 4:38 AM, Mariel Cherkassky wrote:
I'm sure that those tables arent involved in any other transaction when the loop is running. Anything else that I can check ? I think that mybe its connected to some fetching properties but Im not familiar with what settings..

That's the problem.  There are a lot of things that can affect query performance, but most of them won't affect an open cursor unless isolation is low and the query's source tables are changing due to ongoing operations.  Each time the cursor is accessed, the query's source tables are checked for modifications, and if they have been changed, the cursor's query is re-executed ... potentially changing the result set.

Not that it matters here, but you didn't show your actual query.  Even if you are only fetching 100 rows, the query may be doing a lot of work (joins, sorts, etc.) to identify those rows.  If a complicated query is being executed over and over due to ongoing table modifications ...    That's why I suggested using a temporary table that you know won't be modified while the cursor is open on it - it's a way of side-stepping isolation issues that are beyond your control.

If there really is no contention for the source tables, the only other possibilities are a badly over-loaded (or mis-configured) server, a problem with the storage system (e.g., a bad disk that is causing hiccups rather than outright failures), or some unknown issue with the extension you are using.

I'm afraid I'm out of suggestions.
George

pgsql-performance by date:

Previous
From: Moreno Andreo
Date:
Subject: Re: [SPAM] [PERFORM] OS cache management
Next
From: Konstantin Kivi
Date:
Subject: [PERFORM] Poor perfomance of update (and select) on partitioned tables