From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG #4204: COPY to table with FK has memory leak |
Date: | 2008-05-28 20:47:35 |
Message-ID: | 87d4n6p34o.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-05-28 21:45:37 | Re: BUG #4204: COPY to table with FK has memory leak |
Previous Message | Tom Lane | 2008-05-28 20:28:27 | Re: BUG #4204: COPY to table with FK has memory leak |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-05-28 20:55:34 | Re: Avoiding second heap scan in VACUUM |
Previous Message | Simon Riggs | 2008-05-28 20:32:06 | Re: Avoiding second heap scan in VACUUM |