From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Determine if FOR UPDATE or FOR SHARE was used? |
Date: | 2019-03-21 03:31:30 |
Message-ID: | 5C930592.3080206@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/18/19 00:45, Tom Lane wrote:
> I think it would help to take two steps back and ask why you want
> to know this, and what exactly is it that you want to know, anyhow.
> What does it matter if there's FOR SHARE in the query? Does it
I was looking at an old design decision in PL/Java, which implements
java.sql.ResultSet by grabbing a pile of tuples at a time from
SPI_cursor_fetch, and then letting the ResultSet API iterate through
those, until the next pile needs to be fetched.
It seemed like the kind of optimization probably very important in a
client/server connection over RFC 2549, but I'm not sure how important
it is for code running right in the backend.
Maybe it does save a few cycles, but I don't want to be watching when
somebody tries to do UPDATE or DELETE WHERE CURRENT OF.
It occurred to me that positioned update/delete could be made to work
either by simply having the Java ResultSet row fetch operations correspond
directly to SPI fetches, or by continuing to SPI-fetch multiple rows at
a time, but repositioning with SPI_cursor_move as the Java ResultSet
pointer moves through them. (Is one of those techniques common in other
PLs?)
But it also occurred to me that there might be a practical way to
examine the query to see it's one that could be used for positioned
update or delete at all, and avoid any special treatment if it isn't.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-03-21 03:39:38 | Re: MacPorts support for "extra" tests |
Previous Message | Tom Lane | 2019-03-21 03:22:53 | Re: PostgreSQL pollutes the file system |