On 05/26/2014 04:16 PM, Fujii Masao wrote: > On Sun, May 25, 2014 at 6:52 PM, Hannu Krosing <ha...@2ndquadrant.com> wrote: >> On 05/20/2014 01:46 PM, Fujii Masao wrote: >>> On Mon, Mar 17, 2014 at 1:16 PM, Haribabu Kommi >>> <kommi.harib...@gmail.com> wrote: >>>> ... >>>> I Implemented a proof of concept patch to see whether the buffer pool >>>> split can improve the performance or not. >>>> >>>> Summary of the changes: >>>> 1. The priority buffers are allocated as continuous to the shared buffers. >>>> 2. Added new reloption parameter called "buffer_pool" to specify the >>>> buffer_pool user wants the table to use. >>> I'm not sure if storing the information of "priority table" into >>> database is good >>> because this means that it's replicated to the standby and the same table >>> will be treated with high priority even in the standby server. I can imagine >>> some users want to set different tables as high priority ones in master and >>> standby. >> There might be a possibility to override this in postgresql.conf for >> optimising what you described but for most uses it is best to be in >> the database, at least to get started. > Overriding the setting in postgresql.conf rather than that in database might > confuse users because it's opposite order of the priority of the GUC setting. > > Or, what about storig the setting into flat file like replication slot? seems like a good time to introduce a notion of non-replicated tables :)
should be a good fit with logical replication. Cheers Hannu > > Regards, > -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
