Re: Is this the future of I/O for the RDBMS?

Hi again Peter (and thanks again for your input)

> > https://pingcap.com/blog/tikv-and-spdk-pushing-the-limits-of-storage-performance
> > It talks about the Storage Performance Development Kit (SPDK) (spdk.io).


> It looks somewhat similar to Oracle's "raw device tablespaces"

Run far and run fast...

Never worked with it but have vague memories of senior colleagues who
did... some are still in therapy :-)

> Maybe with NVME SSDs
> and persistent memory like Intel Optane it is time to revisit that idea.

Plus ça change... just goes to show that there's rarely anything truly
new in ICT...

> There are less intrusive possibilities, though: Linux has recently
> (kernel 5.1 - oh, that is already 2 years old) aquired a new async I/O
> API named io_uring,

I found this https://thenewstack.io/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/
and a few other bits and pieces - really interesting stuff! I had read
the term io_uring but hadn't appreciated what it was about - it does
add another layer of complexity to my future study of this area -
Linux I/O and db I/O (esp. PG) and how to tie it all together.


> More important for PostgreSQL is whether something like this can be incorporated without changing the overall
architecture:


The one major architectural criticism that I regularly read about PG
is that is uses a process per connection rather than threads:

https://rbranson.medium.com/10-things-i-hate-about-postgresql-20dbab8c2791
#5: Process-Per-Connection = Pain at Scale

I appreciate that the architecture can't be changed for every shiny
new toy that comes along - However, it's frequently interesting though
to look at underlying assumptions and check to see if they're still
valid.


MfG & nochmal Dank.

Pól...

>         hp