On Wed, Mar 4, 2015 at 12:34 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > Out of curiosity, regarding the result materialize code addition, Any > way the caller of "hba_settings" function > "ExecMakeTableFunctionResult" also stores the results in tuple_store. > Is there any advantage > doing it in hba_settings function rather than in the caller?
That might protect against concurrent pg_hba reloads, though I suspect there's a CHECK_FOR_INTERRUPTS hanging out in that loop. We could maybe put one in this loop and check if the parser memory context has been reset. But the immediate problem is that having the API that looked up a line by line number and then calling it repeatedly with successive line numbers was O(n^2). Each time it was called it had to walk down the list from the head all over again. 1 + 2 + 3 + 4 + ... n = n(n+1)/2 or O(n^2). This isn't performance critical but it would not have run in a reasonable length of time for large pg_hba files. And having to store the state between calls means the code is at least as simple for the tuplestore, imho even simpler. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
