[pgpool-hackers: 3748] Re: Using volatile property instead of black_function_list

Umar Hayat m.umarkiani at gmail.com
Wed Jul 29 00:00:59 JST 2020


Hi Tatsuo,
That would be a nice feature. Couple of comments:
1. In case a "user dislikes it". ( as mentioned in the last proposal),  we
will ask users to add some dummy function name to disable this
functionality? or do we really need
an extra flag ?
2. What would be overhead fetching catalog (memory & network usage), we
should document it if it could be significant.

Regards
Umar Hayat
EnterpriseDB: https://edbpostgres.com

On Tue, Jul 28, 2020 at 1:34 PM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > Hi,
> >
> > I am thinking about to use the volatile property of functions to get
> > ride of black_function_list. If this is possible, admins of Pgpool-II
> > do not need to take care of black_function_list, which should make
> > admins life a little bit easier.
> >
> > According to the PostgreSQL manual, non volatile (immutable or stable)
> > functions never do writes to database. Only volatile functions can
> > write to the database. However there are few functions that do not
> > write but have volatile property: random() and timeofday() (there may
> > be others but I do not think of for now). So my proposal would be:
> >
> > 1. If black_function_list is empty, check volatile property of a
> > function. If it is volatile, we regard the function will do writes.
> > If black_function_list is not empty, keep the current behavior.
> >
> > 2. Then check white_function_list. If the function is listed in the
> > list, we do not regard the function do writes. This will be useful if
> > we want to load balance random() or timeofday().
> >
> > Currently if white_function_list is not empty, only functions listed
> > in the list are load balanced. Other functions are regarded as doing
> > writes even if they are immutable or stable. So I think my proposal is
> > better than current behavior in that more functions have a chance to be
> > load balanced.
>
> Actually almost same proposal has been posted by me:-)
>
> https://www.pgpool.net/pipermail/pgpool-hackers/2019-September/003438.html
> ([pgpool-hackers: 3438])
>
> The difference is, in the previous proposal a new config variable to
> fall back to existing behavior was proposed. However as I said in
> above, we can eliminate the new config variable by checking whether
> black_function_list is empty or not.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> _______________________________________________
> pgpool-hackers mailing list
> pgpool-hackers at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20200728/f21dfa80/attachment.html>


More information about the pgpool-hackers mailing list