From: | Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com> |
---|---|
To: | leoaaryan <leoaaryan(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shared memory estimation for postgres |
Date: | 2016-11-11 11:46:57 |
Message-ID: | CAMsr+YFU36Yp3v4SCWJfNouM5ecRKSb71HX9G2KoeeJtvxNF0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 Nov. 2016 13:00, "leoaaryan" <leoaaryan(at)gmail(dot)com> wrote:
>
> Hi Michael,
>
> Thanks for all the help and time. I have already developed a code where I
> can exactly calculate the to be allocated shared memory value based on the
> Postgres 9.5.4 code (i went through the code, found out the sizes and
offset
> of all the structures used in the memory calculation process and then use
> the values from postgres.conf file to calculate the required value).
>
> But the problem is if there is any change in the structures or anything is
> newly added in the next major version, I need to look at the code again
and
> see what changed and then modify the hardcoded values of the structure
size.
> I'm trying to avoid that.
Earlier I suggested adding a command line flag to the backend that, like
--version, prints the desired info and exits.
It's still most unclear to me what the underlying problem you're trying to
solve here is. Why you want this info and why you're so keen to avoid
starting a backend to find it.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-11-11 11:49:22 | Re: Declarative partitioning - another take |
Previous Message | Etsuro Fujita | 2016-11-11 11:30:39 | Re: Push down more UPDATEs/DELETEs in postgres_fdw |