On Wed, Mar 4, 2015 at 12:34 AM, Haribabu Kommi
<kommi.haribabu@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
