| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
| Cc: | Jaime Soler <jaime(dot)soler(at)gmail(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Brad DeJong <bpd0018(at)gmail(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: ResultSet storing all rows with defaulftFetchSize to 5000 |
| Date: | 2018-02-12 18:57:50 |
| Message-ID: | 1921.1518461870@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> writes:
> The backend materializes, so it is a sad thing.
> Is there a change "with hold" can be implemented without materialization?
That would not be an improvement. If we didn't materialize, then we'd
have to retain the locks held by the transaction, as well as keep global
xmin from advancing, so that the rows the cursor still needed to fetch
would not get cleaned by VACUUM nor would the tables containing them get
dropped or significantly altered. Either effect would be awful for
performance if the cursor was held for long. Moreover, keeping the locks
would effectively mean that the transaction wasn't really ended. So if
that's what you want, don't commit the transaction.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Sitnikov | 2018-02-12 19:42:25 | Re: ResultSet storing all rows with defaulftFetchSize to 5000 |
| Previous Message | Vladimir Sitnikov | 2018-02-12 18:50:25 | Re: ResultSet storing all rows with defaulftFetchSize to 5000 |