INSERT
... but execution times did not change at all compared to 100%
fillfactor, why is this ? Does the HOT feature only work if a different
backend accesses the table concurrently ?
Thanks,
Tobias
On Fri, Jul 16, 2021 at 11:27:24PM +0200, Tobias Gierke wrote:
CREATE OR REPLACE FUNCTION paren
Great idea ! This brought the time per INSERT into the parent table down
to a consistent ~0.065ms again (compared to 0.05ms when completely
removing the trigger, so penalty for the trigger is roughly ~20%).
On Sat, 17 Jul 2021 at 16:40, Justin Pryzby wrote:
You could run a single UPDATE rath
Hi,
På onsdag 29. mai 2019 kl. 10:02:50, skrev Tobias Gierke
mailto:tobias.gie...@code-sourcery.de>>:
Hi,
Browsing the PostgreSQL 12 release notes I noticed that JIT is now
enabled by default. Having not followed PostgreSQL development
closely -
does this mea
Hi,
Browsing the PostgreSQL 12 release notes I noticed that JIT is now
enabled by default. Having not followed PostgreSQL development closely -
does this mean that compilation results are now getting cached and
compilation is no longer executed separately for each worker thread in a
parallel
On 06.03.19 18:42, Andres Freund wrote:
It's hard to know precisely without running a profile of the
workload. My suspicion is that the bottleneck in this query is the use
of numeric, which has fairly slow operations, including aggregation. And
they're too complicated to be inlined.
Generally t
Hi,
I was playing around with PG11.2 (i6700k with 16GB RAM, on Ubuntu 18.04,
compiled from sources) and LLVM, trying a CPU-bound query that in my
simple mind should benefit from JIT'ting but (almost) doesn't.
1.) Test table with 195 columns of type 'numeric':
CREATE TABLE test (data0 numeric
