On 12/12/16 22:50, Tomas Vondra wrote: >> +<programlisting> >> +SELECT pg_mv_stats_dependencies_show(stadeps) >> + FROM pg_mv_statistic WHERE staname = 's1'; >> + >> + pg_mv_stats_dependencies_show >> +------------------------------- >> + (1) => 2, (2) => 1 >> +(1 row) >> +</programlisting> >> >> Couldn't this somehow show actual column names, instead of attribute >> numbers? >> > > Yeah, I was thinking about that too. The trouble is that's table-level > metadata, so we don't have that kind of info serialized within the data > type (e.g. because it would not handle column renames etc.). > > It might be possible to explicitly pass the table OID as a parameter of > the function, but it seemed a bit ugly to me.
I think it makes sense to have such function, this is not out function so I think it's ok for it to have the oid as input, especially since in the use-case shown above you can use starelid easily. > > FWIW, as I wrote in this thread, the place where this patch series needs > feedback most desperately is integration into the optimizer. Currently > all the magic happens in clausesel.c and does not leave it.I think it > would be good to move some of that (particularly the choice of > statistics to apply) to an earlier stage, and store the information > within the plan tree itself, so that it's available outside clausesel.c > (e.g. for EXPLAIN - showing which stats were picked seems useful). > > I was thinking it might work similarly to the foreign key estimation > patch (100340e2). It might even be more efficient, as the current code > may end repeating the selection of statistics multiple times. But > enriching the plan tree turned out to be way more invasive than I'm > comfortable with (but maybe that'd be OK). > In theory it seems like possibly reasonable approach to me, mainly because mv statistics are user defined objects. I guess we'd have to see at least some PoC to see how invasive it is. But I ultimately think that feedback from a committer who is more familiar with planner is needed here. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
