Re: delta relations in AFTER triggers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: delta relations in AFTER triggers
Дата
Msg-id CA+TgmobbbJ7+Er2rjVEStAsZeSbkXn5DjGFz_ht-KD6CgJyZnw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@gmail.com>)
Список pgsql-hackers
On Mon, Nov 21, 2016 at 12:04 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> Also, Tsrcache is strangely named: it's not exactly a cache, it's
>> more of a registry.
>
> When I used the word "cache" here, I was thinking more of this
> English language definition:
>
>   a :  a hiding place especially for concealing and preserving
>        provisions or implements
>   b :  a secure place of storage
>
> The intent being to emphasize that there is not one public
> "registry" of such objects, but context-specific collections where
> references are tucked away when they become available for later use
> in the only the appropriate context.  Eventually, when these are
> used for some of the less "eager" timings of materialized view
> maintenance, they may be set aside for relatively extended periods
> (i.e., minutes or maybe even hours) before being used.  Neither
> "registry" nor "cache" seems quite right; maybe someone can think
> of a word with more accurate semantics.

I complained about the use of "cache" in this name before, and I still
think that it is off-base.  I'm not saying there isn't some definition
of the word that could cover what you're doing here, but it's not the
definition that is going to pop to mind for people reading the code.
I think "registry" would be OK; the fact that there is a registry does
not mean it is a global registry; it can be a registry of ephemeral
relations specific to that query.  I'm sure there are other good
choices, too, but, please, not cache!

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



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [sqlsmith] Parallel worker crash on seqscan