MIME-Version: 1.0
From: Jean Baro <jfbaro@gmail.com>
Date: Mon, 20 Dec 2021 15:33:01 -0300
Message-ID: 
 <CA+fQeen2_moUsNxdnydmxyDOGQK3H1groh49AfcQDV-24e6yKQ@mail.gmail.com>
Subject: Would PostgreSQL adapt to a HYPOTHETICAL hardware that grows and
 shrinks as load increases?
To: pgsql-novice@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000009d93e705d3981eeb"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BfQeen2_moUsNxdnydmxyDOGQK3H1groh49AfcQDV-24e6yKQ%40mail.gmail.com>
Precedence: bulk

--0000000000009d93e705d3981eeb
Content-Type: text/plain; charset="UTF-8"

Hi there,

Let's imagine there is a type of Server(Physical, Unikernel, or Hypervisor,
doesn't matter here) that could allocate more RAM, IO bus, Network
bandwidth, or CPU power through API calls. The increase or decrease would
take a few milliseconds to effectively take place.

This hypothetical VM would receive commands from external monitoring tools
that detect load and complex queries (through statistics and ML) and would
decide to adjust the VM size accordingly,

I have a rough idea how complex (or impossible) it would be for ANY modern
database to rely on an always-changing "hardware". As there are many CORE
datasets in memory and statistics around the hardware, so changing this
every now and then seems to require a completely different strategy.

I am not an expert but as I see more and more Serverless solutions tackling
RDBMS, and PostgreSQL being the leader in the cloud world, I was wondering
if one day PostgreSQL could take advantage of these scalable VMs.

   - It seems to me that scaling up could be less complex, as PG wouldn't
   have to select what to invalidate from its cache layers and statistics.
   - Statistics would be affected every time the size of the instance
   changes
   - The instance should probably have a minimum size to avoid cold starts.
   So scaling to zero wouldn't be possible.
   - If the server where the VM/Unikernel is running has no more available
   resources to grow, what should be done (maybe this machine should share
   resources with SPOT only, so it could forcibly deallocate the spot
   instances before increasing the size of the DB VM?)

Any help to educate me on this would be greatly appreciated,

Thanks

--0000000000009d93e705d3981eeb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi there,<br></div><div><br></div><div>Let&#39;s imag=
ine there is a type of Server(Physical, Unikernel, or Hypervisor, doesn&#39=
;t matter here) that could allocate more RAM, IO bus, Network bandwidth, or=
 CPU power through API calls. The increase or decrease would take a few mil=
liseconds to effectively take place.</div><div><br></div><div>This hypothet=
ical VM would receive commands from external monitoring tools that detect l=
oad and complex queries (through statistics and ML) and would decide to adj=
ust the VM size accordingly,</div><div><br></div><div>I have a rough idea h=
ow complex (or impossible) it would be for ANY modern database to rely on a=
n always-changing &quot;hardware&quot;. As there are many CORE datasets in =
memory and statistics around the hardware, so changing this every now and t=
hen seems to require a completely=C2=A0different strategy.</div><div><br></=
div><div>I am not an expert but as I see more and more Serverless solutions=
 tackling RDBMS, and PostgreSQL being the leader in the cloud world, I was =
wondering if one day PostgreSQL could take advantage of these scalable VMs.=
</div><div><ul><li>It seems to me that scaling up could be less complex, as=
 PG wouldn&#39;t have to select what to invalidate from its cache layers an=
d statistics.</li><li>Statistics would be affected every time the size of t=
he instance changes</li><li>The instance should probably have a minimum siz=
e to avoid cold starts. So scaling to zero wouldn&#39;t be possible.</li><l=
i>If the server where the VM/Unikernel is running has no more available res=
ources to grow, what should be done (maybe this machine should share resour=
ces with SPOT only, so it could forcibly deallocate the spot instances befo=
re increasing the size of the DB VM?)</li></ul></div><div>Any help to educa=
te me on this would be=C2=A0greatly appreciated,<br></div><div><br></div><d=
iv>Thanks=C2=A0</div></div>

--0000000000009d93e705d3981eeb--