Re: persistent read cache

From: Steve Atkins <steve(at)blighty(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: persistent read cache
Date: 2018-02-12 17:18:29
Message-ID: 874AB6F0-B9D4-4558-AECD-58C9CE5E63B8@blighty.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


> On Feb 11, 2018, at 5:14 PM, Sand Stone <sand(dot)m(dot)stone(at)gmail(dot)com> wrote:
>
>
> Hi. I wonder if there is such a thing or extension in the PG world.
>
> Here is my use case. I am using PG (PG10 to be more specific) in a
> cloud VM environment. The tables are stored in RAID0 managed SSD
> backed attached storage. Depending on the VM I am using, I usually
> have 256GB local SSD unused.
>
> I wonder if PG could leverage this local SSD as a read (page/block)
> cache, to complement/extend the DRAM by used by shared_buffer today.

It seems something that PostgreSQL could take advantage of, but
it's probably the wrong layer to implement it. If your VM infrastructure
doesn't have any way to use it directly, maybe you could do it at the
drive / filesystem level with something like bcache, lvmcache or
enhanceio?

Adding that sort of complexity to something that needs solid data
integrity makes me nervous, but those solutions have been in the
field for years.

Cheers,
Steve

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Daniel Verite 2018-02-12 17:44:47 Re: execute block like Firebird does
Previous Message Adrian Klaver 2018-02-12 17:08:13 Re: execute block like Firebird does

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-02-12 17:24:04 Re: CALL stmt, ERROR: unrecognized node type: 113 bug
Previous Message Peter Eisentraut 2018-02-12 17:17:48 Re: CALL stmt, ERROR: unrecognized node type: 113 bug