Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzfwh-0001xq-IN for pgsql-novice@arkaria.postgresql.org; Tue, 21 Dec 2021 14:16:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mzfwf-0001gd-Rr for pgsql-novice@arkaria.postgresql.org; Tue, 21 Dec 2021 14:16:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzfwf-0001gT-A7 for pgsql-novice@lists.postgresql.org; Tue, 21 Dec 2021 14:16:49 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mzfwb-0005q4-Qv for pgsql-novice@lists.postgresql.org; Tue, 21 Dec 2021 14:16:47 +0000 Received: by mail-wr1-x42e.google.com with SMTP id v11so27201465wrw.10 for ; Tue, 21 Dec 2021 06:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=sTRKuEY5cOHTDQR/L3YdBfilo9Jjx5vMCNXDbtVtPW8=; b=cn03hQDPOK01Aqz73ZapveA8jzPmT44fRbCf3Yiusy1a/76eEeIGvRSwMoTlwd34V8 HbBNnVNLeMVB3nHlLpudhW0S9AsPLDiHvlT+LDtzGD/43MYedEnd4MJ3iOiut6d61Gxj zmTwAWuHqV9pswVL0ynqoTdLLW8faTCRS9U2cIHN9yBsu3Sf9s5Cgkn1xW7xNwv9mWJQ nUyrGkTGEHJuN3jQ2Bth1kWDYQNcjwAx0d1rMfkA6fIbitoXRulMaxdX1y06Yi4Uq3St MrKTE0x+EvYMqCkyHyE7g4iadJLztgZisu3cwKDaq6YW1nwC6g691qCRAEW8Rti6Rc0E g+lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=sTRKuEY5cOHTDQR/L3YdBfilo9Jjx5vMCNXDbtVtPW8=; b=PAuYUciZtLhZSi8wouxht5dDyvNuqyNNgvukjgMNByOCnlHverf3B0/+k75wEKX3go EY08sJCx1nF7arVdV9a8IKrjDK4CgjNjSMKQtSxUVnYYQ2DyqkE+pAv7iZQZCchi91rp TjH9b+kvzpP2xgtgoT22jcHjjJjF93YTCuZs/Z7hZXTj5Hpp1Y56QtS7C+2ymlJWtAod gBYZCfWJIBCJa+IA4FUfxmNMUaMOUPn2FjeiY8ecMngsCA4rMQpaP/p9VNOuWYLPrLxS zcVO1l9RHiyvFH/eLIxAgkQAZ/4cvD7uRguY+PP1IsVGLLH/XRv0d+obWfwzWtH+ZXHE cp2g== X-Gm-Message-State: AOAM533S9YUugvPc/EEQv+py+QSjzoNoStYPGAYZ4dHxYeqP+IhCXgXv 7UFMXKEF3Rdxg9PCVxxNZsG1DA== X-Google-Smtp-Source: ABdhPJwJtoWMSdcjJ8hMtapcmLToVPopRL1KDksXpgRzv/HI29yDfNDQj5HyP4V95YblH2VRimiY7w== X-Received: by 2002:a5d:5108:: with SMTP id s8mr2854141wrt.477.1640096203433; Tue, 21 Dec 2021 06:16:43 -0800 (PST) Received: from localhost.localdomain (dynamic-ea1g0sp08z8p0f2yb-pd01.res.v6.highway.a1.net. [2001:871:5e:63:d6fd:a607:4c18:b3]) by smtp.gmail.com with ESMTPSA id q8sm6411252wrx.59.2021.12.21.06.16.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Dec 2021 06:16:43 -0800 (PST) Message-ID: <7bc57e3ad40f0baa364d1c3c142f9dccb8f5cb01.camel@cybertec.at> Subject: Re: Would PostgreSQL adapt to a HYPOTHETICAL hardware that grows and shrinks as load increases? From: Laurenz Albe To: Jean Baro , pgsql-novice@lists.postgresql.org Date: Tue, 21 Dec 2021 15:16:42 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2021-12-20 at 15:33 -0300, Jean Baro wrote: > 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?) PostgreSQL does not examine the operating system resources. Doing so would be difficult, because that would have to support all (or at least most of the) operating systems supported by PostgreSQL, and the differences are substantial. On the other hand, there are a couple of parameters, like "effective_cache_size", that tell PostgreSQL something about the operating system resources, and other parameters like "work_mem" that might change with the available resources are configurable at runtime. So while I don't see PostgreSQL "self-tuning", it should be possible to write a piece of software that monitors the resources on a given system and adjusts PostgreSQL accordingly. This will of course never be a "one size fits all", because the correct configuration depends a lot on the workload. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com