Re: Patch: ResourceOwner optimization for tables with many partitions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: ResourceOwner optimization for tables with many partitions
Date
Msg-id 2511.1449774710@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: ResourceOwner optimization for tables with many partitions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: ResourceOwner optimization for tables with many partitions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, sorta.  To be honest, I think this patch is really ugly.  If we
> were going to do this then, yes, I would want to split the patch into
> two parts along those lines.  But actually I don't really want to do
> it this way at all.  It's not that I don't want the performance
> benefits: I do.  But the current code is really easy to read and
> extremely simple, and this changes it into something that is a heck of
> a lot harder to read and understand.  I'm not sure exactly what to do
> about that, but it seems like a problem.

I haven't read the patch in any detail, but keep in mind that part of the
API contract for ResourceOwners is that ResourceOwnerRememberFoo() cannot
fail.  Period.  So any patch that makes those functions less than trivial
is going to be really suspect from a reliability standpoint.  It would be
advisable for example that hash_any not suddenly become covered by the
"must not fail" requirement.

BTW, I do not think you can get away with the requirement that all-zeroes
isn't a valid resource representation.  It might be okay today but it's
hardly future-proof.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Next
From: Simon Riggs
Date:
Subject: Re: Inaccurate results from numeric ln(), log(), exp() and pow()