Exciting! Since I still have the same performance issues on compressed btrfs,
I'm looking forward to testing the patches, probably when a 17 Beta is out and
I can find binaries on my platform (OpenSUSE). It looks like it will make a
huge difference.
Thank you for persisting and getting this
On Wed, Jul 12, 2023 at 1:11 AM Dimitrios Apostolou wrote:
> So would it make sense for postgres to perform reads in bigger blocks? Is it
> easy-ish to implement (where would one look for that)? Or must the I/O unit be
> tied to postgres' page size?
FYI as of last week we can do a little bit of
Hi,
On 2023-07-17 16:42:31 +0200, Dimitrios Apostolou wrote:
> Thanks, it sounds promising! Are the changes in the 16 branch already,
> i.e. is it enough to fetch sources for 16-beta2?
No, this is in a separate branch.
https://github.com/anarazel/postgres/tree/aio
> If so do I just configure
Thanks, it sounds promising! Are the changes in the 16 branch already,
i.e. is it enough to fetch sources for 16-beta2? If
so do I just configure --with-liburing (I'm on linux) and run with
io_method=io_uring? Else, if I use the io_method=worker what is a sensible
amount of worker threads? Should
On Thu, Jul 13, 2023 at 6:50 AM Dimitrios Apostolou wrote:
> Interesting and kind of sad that the last update on the wiki page is from
> 2021. What is the latest prototype? I'm not sure I'm up to the task of
> putting my database to the test. ;-)
It works pretty well, certainly well enough to
Hello and thanks for the feedback!
On Wed, 12 Jul 2023, Thomas Munro wrote:
On Wed, Jul 12, 2023 at 1:11 AM Dimitrios Apostolou wrote:
Note that I suspect my setup being related, (btrfs compression behaving
suboptimally) since the raw device can give me up to 1GB/s rate. It is however
On Wed, Jul 12, 2023 at 5:12 AM Thomas Munro wrote:
> "gathering"
(Oops, for reads, that's "scattering". As in scatter/gather I/O but I
picked the wrong one...).
On Wed, Jul 12, 2023 at 1:11 AM Dimitrios Apostolou wrote:
> Note that I suspect my setup being related, (btrfs compression behaving
> suboptimally) since the raw device can give me up to 1GB/s rate. It is however
> evident that reading in bigger chunks would mitigate such setup
>
Hello list,
I have noticed that the performance during a SELECT COUNT(*) command is
much slower than what the device can provide. Parallel workers improve the
situation but for simplicity's sake, I disable parallelism for my
measurements here by setting max_parallel_workers_per_gather to 0.
