Re: Shared Memory: How to use SYSV rather than MMAP ?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Shared Memory: How to use SYSV rather than MMAP ?
Дата
Msg-id CA+TgmobA9Sz5tgunKrERyzNWtY=J16J+KGzLPstJqBXOWdbwFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Shared Memory: How to use SYSV rather than MMAP ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Dec 26, 2018 at 1:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> You misread what I said.  I don't say that we shouldn't fix this;
> what I'm saying is we should not do so via a user-configurable knob.
> We should be able to auto-configure this and just handle it internally.
> I have zero faith in the idea that users would set the knob correctly.

I don't see how you can auto-configure a performance vs. usability
trade-off.  Remember, the original reason why we switched away from
doing a large System V shared memory allocation is that such
allocations tend to fail due to OS limits.  People who have those
limits set high enough will presumably prefer System V shared memory
allocation, while those who do not will prefer anonymous shared memory
over failure to start.  I guess we could try System V and fall back to
anonymous shared memory, but I think that's masterminding.  It risks
masking a performance problem that the user would like to notice and
fix.

Also, I doubt whether this is the only reason to have a GUC for this.
For instance, I seem to recall that there was some discussion of it
possibly being useful to let developers switch back to the
all-System-V approach for reasons that I don't recall at the moment,
and it even seems possible that somebody might want to use POSIX
shared memory so that they can open up the file that gets created and
inspect the contents using arbitrary tools.  I definitely agree that
an average user probably won't have any idea how to configure settings
like this, so we will want to think carefully about what the platform
defaults should be, but I also think that a GUC-less solution is
depriving those users who ARE smart enough to set the GUC the
opportunity to choose the value that works best for them.

Way back in high school somebody gave me a copy of the Camel book, and
it said something along the lines of: A good programming language
makes simple things simple and difficult things possible.  I thought
then, and still think now, that that's a very wise statement, and I
think it also applies to tools other than programming languages, like,
say, databases. Refusing to add a GUC is just deciding that we don't
trust our users with power tools, and that's not a philosophy with
which I can agree.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: random() (was Re: New GUC to sample log queries)
Следующее
От: John Naylor
Дата:
Сообщение: Re: Speeding up text_position_next with multibyte encodings