On Thu, Jun 12, 2014 at 12:17 AM, Gurjeet Singh <gurj...@singh.im> wrote: > On Wed, Jun 11, 2014 at 10:56 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Jun 10, 2014 at 10:03 PM, Gurjeet Singh <gurj...@singh.im> wrote: >>> And it's probably accepted by now that such a bahviour is not >>> catastrophic, merely inconvenient. >> >> I think the whole argument for having pg_hibernator is that getting >> the block cache properly initialized is important. If it's not >> important, then we don't need pg_hibernator in the first place. But >> if it is important, then I think not loading unrelated blocks into >> shared_buffers is also important. > > I was constructing a contrived scenario, something that would rarely > happen in reality. I feel that the benefits of this feature greatly > outweigh the minor performance loss caused in such an unlikely scenario.
So, are you proposing this for inclusion in PostgreSQL core? If not, I don't think there's much to discuss here - people can use it or not as they see fit, and we'll see what happens and perhaps design improvements will result, or not. If so, that's different: you'll need to demonstrate the benefits via convincing proof points, and you'll also need to show that the disadvantages are in fact minor and that the scenario is in fact unlikely. So far there are zero performance numbers on this thread, a situation that doesn't meet community standards for a performance patch. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers