From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: update with no changes |
Date: | 2021-11-20 14:41:21 |
Message-ID: | aa7e80d2-699c-e626-c96f-44781be1e01e@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/19/21 12:57, Marcos Pegoraro wrote:
>
> I get the idea of letting the server centralize logic like this -
> but frankly if the application is choosing to send all that data
> across the wire just to have the server throw it away the
> application is wasting network I/O. If it does manage its
> resources carefully then the server will never even see an update
> and its behavior here becomes moot.
>
> I understand your point, it´s responsability of application to do what
> it has to do. But lots of times (maybe 98% of them) is not same people
> doing server side and application side. So, Postgres guys will have to
> review all code being done on apps ?
>
> And ok, thanks for explaining me.
suppress_redundant_updates_trigger was created precisely because it's
not always easy to create application code in such a way that it
generates no redundant updates. However, there is a cost to using it,
and the break even point can be surprisingly high. It should therefore
be used with caution, and after appropriate benchmarks.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marcos Pegoraro | 2021-11-20 15:03:26 | Re: update with no changes |
Previous Message | Bharath Rupireddy | 2021-11-20 14:13:11 | rename SnapBuild* macros in slot.c |