From: | Leon Winter <winter-pg(at)bfw-online(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org> |
Subject: | Re: Cursor With_Hold Performance Workarounds/Optimization |
Date: | 2017-10-20 09:11:01 |
Message-ID: | 20171020091101.2qabecra6gvx4zpu@bfw-online.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> When we declare a cursor for a select on the mentioned big table, it takes
> multiple seconds and a big temp file is created which to me seems like the
> materialization took place immediately.
Since you mentioned, Postgres already postponed materialization until commit
operations we checked again and you were right. When we manually checked, we
executed a "declare" statement without opening a transaction block first, which
causes instant materialization. When a transaction is opened, it is in fact
postponed.
Unfortunately we do not use cursors but portals so we can (re-)use prepared
statements in multiple instances and there is not "hold" feature for portals so
we cannot benefit from the lazy "with hold" of the cursor.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-10-20 10:15:16 | Re: More stats about skipped vacuums |
Previous Message | Sokolov Yura | 2017-10-20 08:54:04 | Re: Fix performance degradation of contended LWLock on NUMA |