Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
Tom Lane wrote: > Robert Haas writes: > > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: > >> I don't think it's a bug, I think it's an intentional design tradeoff. > >> To suppress an update in this case, the trigger would have to grovel > >> through the individual fields and detoast them before comparing. > >> That would add a lot of cycles, and only seldom add successes. > >> > >> Possibly we should adjust the documentation so that it doesn't imply > >> that this trigger guarantees to suppress every no-op update. > > > That doesn't sound like a very plausible argument to me. I don't > > think that a proposal to add a function named > > sometimes_suppress_redundant_updates_trigger() would've attracted many > > votes. > > You'd be wrong. The entire point of this trigger is to save cycles, > so having it eat a lot of cycles only to fail is not an improvement. I suppose that either behavior may be desirable depending on circumstances. Maybe it is possible to have each installed trigger be configurable so that it can select either behavior. (Maybe use the trigger argument as a column list, and for each column in the list, do a full detoast and compare instead of relying on toast pointer equality). The current behavior seems more convenient in more cases, and so should remain the default. But this sounds like an additional feature, not a bug. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
Hi, It looks like you know what is happening, but I found that I have made an error in my original assumption: (while the steps to reproduce are still valid) The size of the string at which the trigger does not work as expected varies, depending on the size of the other fields in the row. The 'limit size' is lower if I set bigger values in another text field in the same row (and it seems that it is reached when going above 2000 octet for the texts cells added up). Sorry if this is noise, and thank you for looking into the bug (or documentation error). Regards, Artus de Benque Le lun. 19 juin 2017 à 18:20, Tom Lane a écrit : > Robert Haas writes: > > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: > >> I don't think it's a bug, I think it's an intentional design tradeoff. > >> To suppress an update in this case, the trigger would have to grovel > >> through the individual fields and detoast them before comparing. > >> That would add a lot of cycles, and only seldom add successes. > >> > >> Possibly we should adjust the documentation so that it doesn't imply > >> that this trigger guarantees to suppress every no-op update. > > > That doesn't sound like a very plausible argument to me. I don't > > think that a proposal to add a function named > > sometimes_suppress_redundant_updates_trigger() would've attracted many > > votes. > > You'd be wrong. The entire point of this trigger is to save cycles, > so having it eat a lot of cycles only to fail is not an improvement. > > regards, tom lane >
Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
Robert Haas writes: > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: >> I don't think it's a bug, I think it's an intentional design tradeoff. >> To suppress an update in this case, the trigger would have to grovel >> through the individual fields and detoast them before comparing. >> That would add a lot of cycles, and only seldom add successes. >> >> Possibly we should adjust the documentation so that it doesn't imply >> that this trigger guarantees to suppress every no-op update. > That doesn't sound like a very plausible argument to me. I don't > think that a proposal to add a function named > sometimes_suppress_redundant_updates_trigger() would've attracted many > votes. You'd be wrong. The entire point of this trigger is to save cycles, so having it eat a lot of cycles only to fail is not an improvement. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: >> Seems like in "suppress_redundant_updates_trigger" we are comparing >> toasted tuple with the new tuple and that is the cause of the bug. > > I don't think it's a bug, I think it's an intentional design tradeoff. > To suppress an update in this case, the trigger would have to grovel > through the individual fields and detoast them before comparing. > That would add a lot of cycles, and only seldom add successes. > > Possibly we should adjust the documentation so that it doesn't imply > that this trigger guarantees to suppress every no-op update. That doesn't sound like a very plausible argument to me. I don't think that a proposal to add a function named sometimes_suppress_redundant_updates_trigger() would've attracted many votes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
Dilip Kumar writes:
> On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque
> wrote:
>> postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1;
>> UPDATE 0
>> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
>> UPDATE 1
>> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
>> UPDATE 1 <--- BUG: expected 0, as we ran the same update twice
> Seems like in "suppress_redundant_updates_trigger" we are comparing
> toasted tuple with the new tuple and that is the cause of the bug.
I don't think it's a bug, I think it's an intentional design tradeoff.
To suppress an update in this case, the trigger would have to grovel
through the individual fields and detoast them before comparing.
That would add a lot of cycles, and only seldom add successes.
Possibly we should adjust the documentation so that it doesn't imply
that this trigger guarantees to suppress every no-op update.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque
wrote:
> postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1;
> UPDATE 0
> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
> UPDATE 1
> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1;
> UPDATE 1 <--- BUG: expected 0, as we ran the same update twice
Seems like in "suppress_redundant_updates_trigger" we are comparing
toasted tuple with the new tuple and that is the cause of the bug.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
