On Jun 3, 2006, at 10:27 AM, Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
moving a lot of overhead into SELECT in order to make UPDATE cheaper,
and on top of that the restriction to same-page
On Jun 3, 2006, at 2:05 PM, Nicolai Petri wrote:
On Saturday 03 June 2006 17:27, Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
[snip - complicated update logic proprosal]
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
[snip - ... bad i
On Saturday 03 June 2006 17:27, Tom Lane wrote:
> PFC <[EMAIL PROTECTED]> writes:
> >[snip - complicated update logic proprosal]
> > What do you think ?
>
> Sounds enormously complicated and of very doubtful net win --- you're
>
> [snip - ... bad idea reasoning] :)
What if every backend wh
PFC <[EMAIL PROTECTED]> writes:
> What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
moving a lot of overhead into SELECT in order to make UPDATE cheaper,
and on top of that the restriction to same-page will limit the
usefulness quite a lot (unless we d
Hello,
Sometimes people complain that UPDATE is slow in postgres. UPDATE...
- generates dead tuples which must be vacuumed.
- needs to hit all indexes even if only one column was modified.
From what I know UPDATE creates a new copy of the old row with the
rele
