From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Artus de benque <artusdebenque(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger |
Date: | 2017-06-19 21:31:59 |
Message-ID: | 6de6cf32-92fa-f1ea-9c88-580fea72f3c6@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 06/19/2017 05:19 PM, David G. Johnston wrote:
> At first glance I think I'd rather have it do the correct thing all of
> the time, even if it takes longer, so that my only trade-off decision
> is whether to improve performance by fixing the application.
>
> Ideally if the input tuple wouldn't require compression we wouldn't
> bother to decompress the stored tuple.
That looks like one reasonable elimination check.
I wonder how much closer it could get with some changes that wouldn't
necessarily use many more cycles.
One might be a less_easy queue; marching through the tuple
comparing fields, if one is found to be TOASTed, throw it
on the queue and march on. Only if all the easy ones matched
is there any point in looking at the queue.
At that point, there could be a tunable for how much effort
to expend. Perhaps I'm willing to decompress an inline value,
but not retrieve an out-of-line one? For the TOAST compression
algorithm I'm not sure of the balance between compression
and decompression effort; I know gzip decompression is pretty cheap.
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Mohamed Akram | 2017-06-20 13:57:13 | Re: BUG #14670: uuid_generate_v3 and uuid_generate_v5 do not support binary names |
Previous Message | David G. Johnston | 2017-06-19 21:19:22 | Re: [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-06-19 21:39:42 | Re: CREATE SUBSCRIPTION documentation |
Previous Message | Peter Eisentraut | 2017-06-19 21:25:16 | Re: psql's \d and \dt are sending their complaints to different output files |