Re: BUG #4204: COPY to table with FK has memory leak

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: BUG #4204: COPY to table with FK has memory leak
Дата
Msg-id 87d4n6p34o.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: BUG #4204: COPY to table with FK has memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> This is expected to take lots of memory because each row-requiring-check
>>> generates an entry in the pending trigger event list.
>
>> Hm, it occurs to me that we could still do a join against the pending event
>> trigger list... I wonder how feasible it would be to store the pending trigger
>> event list in a temporary table instead of in ram.
>
> We could make that list spill to disk, but the problem remains that
> verifying the rows one at a time will take forever.

Well I was thinking if we did a join between a temporary table and the fk
target then it wouldn't have to be a one-by-one operation. It could be a merge
join if the planner thought that was better. How to get accurate stats into
the planner at that point would be a missing detail though.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Avoiding second heap scan in VACUUM
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Avoiding second heap scan in VACUUM