Re: Huge memory consumption on partitioned table with FKs

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Huge memory consumption on partitioned table with FKs
Дата
Msg-id CA+HiwqG0dOKxB8xj=Brf1jcwvdtdL6mLCEkSpDDUUMe2QhEeaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Huge memory consumption on partitioned table with FKs  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Tue, Dec 1, 2020 at 12:25 PM Corey Huinker <corey.huinker@gmail.com> wrote:
> On Mon, Nov 30, 2020 at 9:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Corey Huinker <corey.huinker@gmail.com> writes:
>> > Given that we're already looking at these checks, I was wondering if this
>> > might be the time to consider implementing these checks by directly
>> > scanning the constraint index.
>>
>> Yeah, maybe.  Certainly ri_triggers is putting a huge amount of effort
>> into working around the SPI/parser/planner layer, to not a lot of gain.
>>
>> However, it's not clear to me that that line of thought will work well
>> for the statement-level-trigger approach.  In that case you might be
>> dealing with enough tuples to make a different plan advisable.
>
> Bypassing SPI would probably mean that we stay with row level triggers, and the cached query plan would go away,
perhapsreplaced by an already-looked-up-this-tuple hash sorta like what the cached nested loops effort is doing.
 
>
> I've been meaning to give this a try when I got some spare time. This may inspire me to try again.

+1 for this line of work.

-- 
Amit Langote
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Huge memory consumption on partitioned table with FKs
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW