po 16. 12. 2019 v 14:02 odesílatel Mariel Cherkassky <
mariel.cherkas...@gmail.com> napsal:
> I see, thank u !
> Maybe I didnt see big difference because most of my tables arent so big.
> My db`s size is 17GB and the largest table contains about 20M+ records.
>
Postgres 12 has enabled JIT by
I see, thank u !
Maybe I didnt see big difference because most of my tables arent so big. My
db`s size is 17GB and the largest table contains about 20M+ records.
Thanks again !
degredation after upgrade from 9.6 to 12
Hey Jeff,Andrew,
I continued testing the 12version vs the 96 version and it seems that there is
almost non diff and in some cases pg96 is faster than 12. I compared the
content of pg_stat_statements after each test that I have done and it seems
that the db
Hey Jeff,Andrew,
I continued testing the 12version vs the 96 version and it seems that there
is almost non diff and in some cases pg96 is faster than 12. I compared the
content of pg_stat_statements after each test that I have done and it seems
that the db time is almost the same and sometimes 96
On Sun, Nov 24, 2019 at 1:05 PM Mariel Cherkassky <
mariel.cherkas...@gmail.com> wrote:
> Hey Jeff,
> This example was only used to show that pg96 had better perfomance than
> pg12 in a very simple case.
>
OK, but do you agree that a 15% slow down is more realistic than 3 fold
one? Or are you
Op 24-11-2019 om 19:05 schreef Mariel Cherkassky:
Hey Jeff,
This example was only used to show that pg96 had better perfomance
than pg12 in a very simple case.
In all the tests that I run most of the queries took less time on
9.6`s version. I dont know why, but as you can see after
On Sun, Nov 24, 2019 at 8:52 AM Mariel Cherkassky <
mariel.cherkas...@gmail.com> wrote:
> Hey Andrew,
> It seems that changing this parameter worked for me.
> Setting it to zero means that there wont be any parallel workers for one
> query right ?
> Is it something familiar this problem with the
Hey Andrew,
It seems that changing this parameter worked for me.
Setting it to zero means that there wont be any parallel workers for one
query right ?
Is it something familiar this problem with the gatherers ?
Hi there -
I have same feelings. Try set max_parallel_workers_per_gather to zero. I don't
think that comparison non-parallel and parallel versions is correct (don't say
anything about parallel in 9.6 pls)
What explain says? I suppose you will have different exec plans. Optimizer
stranges of
Hello,
did you run ananlyze on your db?
Le dim. 24 nov. 2019 à 13:53, Mariel Cherkassky
a écrit :
> Hey all,
> I'm testing performance of two identical machines one in 9.6 and the
> second one is in 12. The second machine is a clone of the first one + db
> upgrade to 12 beta 3 (Yes I'm aware
Hey all,
I'm testing performance of two identical machines one in 9.6 and the second
one is in 12. The second machine is a clone of the first one + db upgrade
to 12 beta 3 (Yes I'm aware 12.1 was released).
machine stats :
32gb ram
8 cpu
regular hd (not ssd)
my postgresql.confg settings:
11 matches
Mail list logo
