On Wed, Sep 16, 2020 at 9:14 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Ashutosh Sharma <ashu.coe...@gmail.com> writes: > > On Wed, Sep 16, 2020 at 1:25 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> * Should any of the other tables in the test be converted to temp? > > > Are you trying to say that we can achieve the things being done in > > test-case 1 and 2 by having a single temp table and we should aim for > > it because it will make the test-case more efficient and easy to > > maintain? > > Well, I'm just looking at the comment that says the reason for the > begin/rollback structure is to keep autovacuum's hands off the table. > In most if not all of the other places where we need that, the preferred > method is to make the table temp or mark it with (autovacuum = off). > While this way isn't wrong exactly, nor inefficient, it does seem > a little restrictive. For instance, you can't easily test cases that > involve intentional errors. > > Another point is that we have a few optimizations that apply to tables > created in the current transaction. I'm not sure whether any of them > would fire in this test case, but if they do (now or in the future) > that might mean you aren't testing the usual scenario for use of > pg_surgery, which is surely not going to be a new-in-transaction > table. (That might be an argument for preferring autovacuum = off > over a temp table, too.) >
I agree with you on both the above points. I'll try to make the necessary changes to address all your comments. Also, I'd prefer creating a normal heap table with autovacuum = off over the temp table for the reasons you mentioned in the second point. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
