Do we really need to switch to per-tuple memory context inATRewriteTable() when Table Rewrite is not happening
От | Ashutosh Sharma |
---|---|
Тема | Do we really need to switch to per-tuple memory context inATRewriteTable() when Table Rewrite is not happening |
Дата | |
Msg-id | CAE9k0P=1R1OfCp3hUMs1=5CV0TB5xM9J1+mntPjKuVgFvcGG=g@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Do we really need to switch to per-tuple memory context inATRewriteTable() when Table Rewrite is not happening
Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening |
Список | pgsql-hackers |
Hi All, Today while trying to understand the code for ALTER TABLE in PostgreSQL (basically the table rewrite part), I noticed that we are switching to a per-tuple memory context even when table rewrite is not required. For e.g.. consider the case where we do ADD CONSTRAINTS (NOT NULL or CHECK) using ALTER TABLE command. In this case, we just scan the tuple and verify it for the given constraint instead of forming a new tuple. So, not sure why do we switch to per-tuple memory context when just adding the constraint. Could someone please let me know the reason for doing so. Thanks in advance. I am basically talking about the following lines of code in ATRewriteTable() function. /* * Switch to per-tuple memory context and reset it for each tuple * produced, so we don't leak memory. */ oldCxt = MemoryContextSwitchTo(GetPerTupleMemoryContext(estate)); AFAICU, we should have done that only when 'tab->rewrite > 0' is true or may be when 'OIDNewHeap' is valid. Here are the steps that i have followed to understand ATRewriteTable(), CREATE TABLE tmp (initial int4); INSERT INTO tmp VALUES(10); INSERT INTO tmp VALUES(20); ALTER TABLE tmp ADD CONSTRAINT check_cons CHECK (initial > 5); ALTER TABLE tmp ALTER COLUMN initial SET NOT NULL; -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: