On Sat, Mar 23, 2013 at 1:50 AM, Bertrand Janin wrote:
> Tom is right, this would be an optimization for a corner case, I noticed this
> when running a generated script for a batch update that wasn't given a ton of
> attention. The BEFORE UPDATE trigger will work great.
If you know the app, just
On 2013-03-22, Ryan Kelly wrote:
> On Fri, Mar 03/22/13, 2013 at 06:16:11AM -0700, Adrian Klaver wrote:
>> On 03/22/2013 05:32 AM, Bertrand Janin wrote:
>> >I noticed how rows were re-written to a different location (new ctid) even
>> >without changes to the values. This illustrate what I mean:
>>
Hannes Erven writes:
> On 2013-03-22 13:32, Bertrand Janin wrote:
>>> UPDATE demo
>>> SET value = value
>>> WHERE id = 1;
> On 2013-03-22 14:55, Tom Lane wrote:
>> It's not *necessary* to do so. However, avoiding it would require
>> sitting there and comparing the old and new tuples,
> But in t
Hannes Erven wrote :
> Hi folks,
>
>
> On 2013-03-22 13:32, Bertrand Janin wrote:
> >UPDATE demo
> >SET value = value
> >WHERE id = 1;
>
>
> On 2013-03-22 14:55, Tom Lane wrote:
> >
> >It's not *necessary* to do so. However, avoiding it would require
> >sitting there and comparing
Hi folks,
On 2013-03-22 13:32, Bertrand Janin wrote:
>UPDATE demo
>SET value = value
>WHERE id = 1;
On 2013-03-22 14:55, Tom Lane wrote:
>
It's not *necessary* to do so. However, avoiding it would require
sitting there and comparing the old and new tuples,
But in this case, no
Ryan Kelly wrote:
> I'm having trouble understanding why it is necessary to generate a new
> tuple even when nothing has changed. It seems that the OP understands
> that MVCC is at work, but is questioning why this exact behavior occurs.
> I too have the same question.
>
> Perhaps you could provi
On 03/22/2013 06:41 AM, Ryan Kelly wrote:
On Fri, Mar 03/22/13, 2013 at 06:16:11AM -0700, Adrian Klaver wrote:
On 03/22/2013 05:32 AM, Bertrand Janin wrote:
I noticed how rows were re-written to a different location (new ctid) even
without changes to the values. This illustrate what I mean:
Ryan Kelly writes:
> I'm having trouble understanding why it is necessary to generate a new
> tuple even when nothing has changed. It seems that the OP understands
> that MVCC is at work, but is questioning why this exact behavior occurs.
> I too have the same question.
It's not *necessary* to do
On Fri, Mar 03/22/13, 2013 at 06:16:11AM -0700, Adrian Klaver wrote:
> On 03/22/2013 05:32 AM, Bertrand Janin wrote:
> >I noticed how rows were re-written to a different location (new ctid) even
> >without changes to the values. This illustrate what I mean:
> >
> > CREATE TABLE demo (id serial,
Adrian Klaver wrote:
> On 03/22/2013 05:32 AM, Bertrand Janin wrote:
>> I noticed how rows were re-written to a different location (new ctid) even
>> without changes to the values. This illustrate what I mean:
>> -- ctid = (0,1)
>> SELECT id, xmin, ctid, value
>> FROM demo
>> W
On 03/22/2013 05:32 AM, Bertrand Janin wrote:
I noticed how rows were re-written to a different location (new ctid) even
without changes to the values. This illustrate what I mean:
CREATE TABLE demo (id serial, value text);
-- generate a few pages of dummy data
INSERT INTO demo (
I noticed how rows were re-written to a different location (new ctid) even
without changes to the values. This illustrate what I mean:
CREATE TABLE demo (id serial, value text);
-- generate a few pages of dummy data
INSERT INTO demo (value)
SELECT md5(s.a::text)
FROM gener
12 matches
Mail list logo
