On Wed, Mar 4, 2015 at 12:18 PM, Greg Stark <st...@mit.edu> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
