Add LogicalTapeSetExtend() to logtape.c
От | Jeff Davis |
---|---|
Тема | Add LogicalTapeSetExtend() to logtape.c |
Дата | |
Msg-id | e54bfec11c59689890f277722aaaabd05f78e22c.camel@j-davis.com обсуждение исходный текст |
Ответы |
Re: Add LogicalTapeSetExtend() to logtape.c
|
Список | pgsql-hackers |
Attached is a patch that exports a new function from logtape.c: extern LogicalTapeSet *LogicalTapeSetExtend( LogicalTapeSet *lts, int nAdditional); The purpose is to allow adding new tapes dynamically for the upcoming Hash Aggregation work[0]. HashAgg doesn't know in advance how many tapes it will need, though only a limited number are actually active at a time. This was proposed and originally written by Adam Lee[1] (extract only the changes to logtape.c/h from his posted patch). Strangely, I'm seeing ~5% regression with his version when doing: -- t20m_1_int4 has 20 million random integers select * from t20m_1_int4 order by i offset 100000000; Which seems to be due to using a pointer rather than a flexible array member (I'm using gcc[2]). My version (attached) still uses a flexible array member, which doesn't see the regression; but I repalloc the whole struct so the caller needs to save the new pointer to the tape set. That doesn't entirely make sense to me, and I'm wondering if someone else can repro that result and/or make a suggestion, because I don't have a good explanation. I'm fine with my version of the patch, but it would be nice to know why there's such a big difference using a pointer versus a flexible array member. Regards, Jeff Davis [0] https://postgr.es/m/6e7c269b9a84ff75fefcad8ab2d4758f03581e98.camel%40j-davis.com [1] https://postgr.es/m/20200108071202.GA1511@mars.local [2] gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Вложения
В списке pgsql-hackers по дате отправления: