Re: pg_shmem_allocations view

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: pg_shmem_allocations view
Дата
Msg-id CA+U5nMLkpBH08HaZYt_tMYLqXeSL_DwnCBe2h4M4788HcTiN2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_shmem_allocations view  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_shmem_allocations view
Список pgsql-hackers
On 5 May 2014 21:54, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, May 5, 2014 at 3:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Sun, May 4, 2014 at 7:50 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>>>> Thinking about this, I think it was a mistake to not add a 'name' field
>>>> to dynamic shared memory's dsm_control_item.
>>
>>> Well, right now a dsm_control_item is 8 bytes.  If we add a name field
>>> of our usual 64 bytes, they'll each be 9 times bigger.
>>
>> And the controlled shared segment is likely to be how big exactly?  It's
>> probably not even possible for it to be smaller than a page size, 4K or
>> so depending on the OS.  I agree with Andres that a name would be a good
>> idea; complaining about the space needed to hold it is penny-wise and
>> pound-foolish.
>
> The control segment is sized to support a number of dynamic shared
> memory segments not exceeding 64 + 2 *MaxBackends.  With default
> settings, that currently works out to 288 segments, or 2306 bytes.
> So, adding a 64-byte name to each of those structures would increase
> the size from 2k to about 20k.
>
> So, sure, that's not a lot of memory.  But I'm still not convinced
> that's it's very useful.  What I think is going to happen is that (1)
> most people won't be used dynamic shared memory at all, so they won't
> have any use for this; (2) those people who do run an extension that
> uses dynamic shared memory will most likely only be running one such
> extension, so they won't need a name to know what the segments are
> being used for; and (3) if and when we eventually get parallel query,
> dynamic shared memory segments will be widely used, but a bunch of
> segments that are all named "parallel_query" or "parallel_query.$PID"
> isn't going to be too informative.

Not sure your arguments hold any water.

Most people don't use most features... and so we're not allowed
features that can be debugged?
How do you know people will only use one extension that uses dshmem?
Why would we call multiple segments the same thing??

If names are a problem, lets give them numbers. Seems a minor point.
Perhaps we can allocate space for names dynamically??

Not being able to tell segments apart from each other is just daft, if
we are trying to supply bug free software for the world to use.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: Problem with txid_snapshot_in/out() functionality)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_shmem_allocations view