ibench.beelink.pg16b.1u.1tno.1g/all.html#summary
r5) 4 tables, 4 clients -
https://mdcallag.github.io/reports/23_05_04_ibench.beelink.pg16b.4u.1tno.1g/all.html#summary
r6) 1 table, 4 clients -
https://mdcallag.github.io/reports/23_05_04_ibench.beelink.pg16b.4u.1tyes.1g/all.html#summary
--
in <= 16G. But that is a problem for another day. The IPS vs time graphs
are not a flat line, but I am not ready to pursue that as problem unless it
shows multi-second write-stalls (fortunately it does not).
--
Mark Callaghan
mdcal...@gmail.com
On Fri, May 5, 2023 at 10:01 PM MARK CALLAGHAN wrote:
> I have two more runs of the benchmark in progress so we will have 3
> results for each of the test cases to confirm that the small regressions
> are repeatable.
>
They get similar results. Then I tried Linux perf but the hiera
t; anyway, right?), but perhaps that could depend on a GUC. Likewise for
> base backup. Etc. Then someone concerned about hitting the 16TB
> limit on ext4 could opt out. Or something like that. It seems funny
> though, that's exactly the user who should want this feature (they
> have 16,000 relation segment files).
>
>
>
--
Mark Callaghan
mdcal...@gmail.com
ng to keep the table small enough to fit in the
Postgres buffer pool. I also have results from tables that are much larger
than memory, and even in that case the problem can be reproduced.
--
Mark Callaghan
mdcal...@gmail.com
wrote:
> On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN wrote:
> > On small servers I have at home I can reproduce the problem without
> concurrent queries and 17beta2 is 5% to 10% slower there.
> >
> > The SQL statement for the scan microbenchmark is:
> > SELECT * from
A writeup for the benchmark results is here -
https://smalldatum.blogspot.com/2024/07/postgres-17beta2-vs-sysbench-looking.html
pg17beta2 and pg17beta1 look good so far
On Mon, Jul 8, 2024 at 10:49 AM MARK CALLAGHAN wrote:
> My results have too much variance so this is a false alarm. One da
On Fri, May 12, 2023 at 4:02 PM Thomas Munro wrote:
> On Sat, May 13, 2023 at 4:41 AM MARK CALLAGHAN wrote:
> > Repeating what was mentioned on Twitter, because I had some experience
> with the topic. With fewer files per table there will be more contention on
> the per-inode mut
On Tue, May 9, 2023 at 10:36 AM MARK CALLAGHAN wrote:
>
>
> On Fri, May 5, 2023 at 10:01 PM MARK CALLAGHAN wrote:
>
>> I have two more runs of the benchmark in progress so we will have 3
>> results for each of the test cases to confirm that the small regressions
&
On Fri, May 19, 2023 at 4:04 PM Andres Freund wrote:
> With "yet to see any significant changes" do you mean that the runs are
> comparable with earlier runs, showing the same regression? Or that the
> regression vanished? Or ...?
>
I mean that I might be chasing noise and the mean+stddev for th
-> Index Scan using sbtest1_pkey on sbtest1 (cost=0.44..589.80
rows=10068 width=121) (actual time=0.024..3.478 rows=10001 loops=1)
Index Cond: ((id >= 1000) AND (id <= 1001))
Planning Time: 0.039 ms
Execution Time: 18.265 ms
--
Mark Callaghan
mdcal...@gmail.com
Results for 16 beta1 are similar to what I shared above:
* no regressions
* a few queries are >= 1.5 times faster which make the read-only
transaction >= 1.5 times faster
http://smalldatum.blogspot.com/2023/05/postgres-16beta1-looks-good-vs-sysbench.html
--
Mark Callaghan
mdcal...@gmail.com
s was with glibc). Low cardinality inputs were more
> like 2.5x.
>
> I believe that ICU is faster than glibc in general -- even with
> TRUST_STRXFRM enabled. But the TRUST_STRXFRM thing is bound to be the
> most important factor here, by far.
>
> --
> Peter Geoghegan
>
--
Mark Callaghan
mdcal...@gmail.com
13 matches
Mail list logo
