Re: [HACKERS] VACUUM ANALYZE problem on linux
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Дата | |
Msg-id | m109tmj-000EBRC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] VACUUM ANALYZE problem on linux (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] VACUUM ANALYZE problem on linux
|
Список | pgsql-hackers |
> > Oleg Broytmann <phd@sun.med.ru> writes: > > Hello! > > A week ago I reported a problem with VACUUM ANALYZE on linux and memory > > error. Three good guys saw my database and two of them for VACUUM problem, > > I hope (Tom Lane and Thomas Lockhart). > > Have you reproduced the case? > > Oh! I'm sorry, I thought I saw a report that someone had already fixed > the problem, so I didn't look at it. Maybe a little misunderstanding. Oleg reported a memory exhaustion problem on COPY FROM in the same context (which also happened on large updates). I've tracked that down in the executor. It was because his table had a CHECK clause and that got stringToNode()'ed for each single tuple. This problem is fixed in CURRENT along with a speedup of factor 2++ for the case of CHECK on large ranges. The check's are only once stringToNode()'ed now and live until the executor's memory context get's destroyed (the portal level the plan is executed in). I don't know if the same caused the VACUUM problem. Oleg, could you please check against the CURRENT source tree if the problem still exists? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: