Re: [HACKERS] get_relation_stats_hook()

On Thu, 2008-07-10 at 14:59 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Thu, 2008-06-26 at 12:50 -0400, Tom Lane wrote:
> >> I think you need to move up a level, and perhaps refactor some of the
> >> existing code to make it easier to inject made-up stats.
>
> > I've looked at ways of refactoring this, but the hooks provided here
> > complement the existing functionality fairly well.
>
> The hooks proposed here are completely useless --- it's impossible
> to return anything except actual catalog data, because whatever is
> returned is going to be subjected to ReleaseSysCache() later on.
> I'd think you at least need to be able to turn that into a no-op,
> or perhaps a pfree() call. Also it's clear that some calls of
> examine_variable would still return regular syscache entries, so
> the cleanup behavior has to be determinable on a per-call basis.

I've introduced an additional plugin function

typedef void (*release_relation_stats_hook_type) (HeapTuple statstup);

Simply pfree-ing things would prevent the plugin from sometimes
returning a syscache entry or keeping its own cache internally.

> I also still think that you need to reconsider the level at which
> the hook gets control. It's impossible given these hook definitions
> to create "fake" data for an appendrel or sub-SELECT, which seems to
> me to be an important requirement, at least till such time as the
> core planner handles those cases better.

I agree with this, especially with regard to join relations.

However, I'm having difficulty seeing how to identify these structures
externally to allow any meaningful lookups of data. So if we have a 7
table join, then how do we specifically identify the join between tables
4 and 7, say.

We can say, its "foo = foo", but that can easily occur multiple times in
a many way join, especially since join columns are frequently named the
same. How should we tell them apart? AFAICS we can't and yet we need to
if this is to be useful.

Overriding that is already reasonably easily possible anyway using
operators, so I'm not seeing this plugin as a way to introduce hints.
This is purely to provide access to alternate stats.

> My feeling is that the hooks ought to be at more or less the same
> semantic level as examine_variable and ReleaseVariableStats, and that
> rather than making special-case hooks for the other couple of direct
> accesses to STATRELATT, the right thing is to make sure that the
> examine_variable hook will work for them too.

In general, I agree, though this does cause more work in the plugin and
in other areas of selfuncs.c

btcostestimate() searches syscache directly rather than going through
examine_variable. I suspect refactoring that would cause changes to
internals of examine_variable, possibly also changing the API to cater
for index stats.

I have tried to follow this through as you suggest, but the thought that
examine_variable is the right level doesn't seem as clean as it sounded
when you first suggested.

With those problems in mind, can we stick to the original plan? It's
reasonably clear how it works, and it does work correctly now with the
new release call mentioned above.

Or can you suggest the refactoring you would like to see in that area?
Or better still commit something for me to use as a base.

> I think it might be a good idea to prepare an actual working example
> of a plug-in that does something with the hook in order to verify
> that you've got a useful definition.

I've tested this new patch with the plugin I showed you before, rewired
so it makes syscache calls via patch, as a "null" test case.
All works, no problems.

I'll submit the fully working plugin once we've stabilised the API. It's
designed as a contrib module, so it can go in pgfoundry or contrib.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support