On Wed, Mar 4, 2015 at 12:18 PM, Greg Stark <stark@mit.edu> wrote:
> 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.
I feel there is no problem of current pg_hba reloads, because the
check_for_interrupts
doesn't reload the conf files. It will be done in the "postgresMain"
function once the
query finishes. Am I missing something?
+ foreach(line, parsed_hba_lines)
In the above for loop it is better to add "check_for_interrupts" to
avoid it looping
if the parsed_hba_lines are more.
> 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.
Got it. Thanks.
Regards,
Hari Babu
Fujitsu Australia