On 11/20/21 10:03, Marcos Pegoraro wrote:
>
> 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
>
> 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
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
On Fri, Nov 19, 2021 at 10:20 AM Andres Freund wrote:
> You can't just skip doing updates without causing problems.
>
>
Given you can do exactly this by using a trigger this statement is either
false or I'm missing some piece of knowledge it relies upon.
David J.
>
> I suppose if the application side cannot be trusted to code to a
> specification without having the server side add validation and/or
> compensation code to catch the bugs then, yes, one option is to have the
> server side do extra work. There are other solutions, some of which are
> not even
On Fri, Nov 19, 2021 at 10:57 AM Marcos Pegoraro wrote:
> So, Postgres guys will have to review all code being done on apps ?
>>
>
>
I suppose if the application side cannot be trusted to code to a
specification without having the server side add validation and/or
compensation code to catch the
>
> 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
>
On Fri, Nov 19, 2021 at 10:03 AM Marcos Pegoraro wrote:
> Because it takes resources to determine that nothing changed. If you want
>> to opt-in into that there is even an extension trigger that makes doing so
>> fairly simple. But it's off by default because the typical case is that
>> people
Marcos Pegoraro writes:
> But it takes resources for other operations, right ?
> I think this is not unusual. If an user double click on a grid, just sees a
> record and clicks ok to save, probably that application calls an update
> instead of seeing if some field were changed before that.
[
Hi,
On November 19, 2021 8:38:25 AM PST, Marcos Pegoraro wrote:
>Why this happens ?
>
>create table t(i int);
>CREATE TABLE
>insert into t values(1);
>INSERT 0 1
>select (ctid::text::point)[1]::int, * from t;
> ctid | i
>--+---
>1 | 1
>(1 row)
>update t set i = i;
>UPDATE 1
>select
>
> Because it takes resources to determine that nothing changed. If you want
> to opt-in into that there is even an extension trigger that makes doing so
> fairly simple. But it's off by default because the typical case is that
> people don't frequently perform no-op updates so why eat the
On Fri, Nov 19, 2021 at 9:38 AM Marcos Pegoraro wrote:
> If nothing was changed, why create a new record, append data to wal, set
> old record as deleted, etc, etc ?
>
Because it takes resources to determine that nothing changed. If you want
to opt-in into that there is even an extension
Why this happens ?
create table t(i int);
CREATE TABLE
insert into t values(1);
INSERT 0 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
1 | 1
(1 row)
update t set i = i;
UPDATE 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
2 | 1
(1 row)
If
13 matches
Mail list logo
