On Mon, 11 Oct 2010 13:22:13 -0400
Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 7:20 AM, Shigeru HANADA
> <hanada@metrosystems.co.jp> wrote:
> > In this step, optimizer calls FdwRoutine->GetStatistics() to get
> > estimated costs of the foreign scan. ?FDW can calculate costs by
> > itself with some statistics, or get costs from remote-side, or leave
> > the costs as is.
>
> I think this should be called EstimateCosts rather than GetStatistics.
Agreed, the name you suggested would be better.
I've chosen the name GetStatistics because a function with that name
is defined in SQL/MED standard as below, but GetStatistics might
rather match handling of ANALYZE request in PostgreSQL.
Section 22.3.28 GetStatistics (ISO/IEC 9075-9:2003) > Retrieve implementation-defined statistics associated with a
> foreign server request.
> > Maybe DBAs want to see how much and what kind of connections are
> > established now, so we should show list of active connections via a
> > view or function. ?To treat connections transparently, I propose
> > that connection pooling mechanism in the core module, not in each FDW
> > module. ?Or should we add API to return list of active connections in
> > common format?
>
> I think for starters we should make this the responsibility of each
> FDW. It seems a bit hard to speculate about what we might want down
> the road at this point.
Agreed. I would move connection cache mechanism to postgresql_fdw.
I also would remove pg_foreign_connections view because it might need
new interface to get list of active connections from FDWs.
> > Should we add API which is called from ANALYZE to allow FDWs to handle
> > statistics when user wants.
>
> I would probably put this off also, to a later phase of the project.
Agreed.
Thanks for the review!
I'll finish the SQL/MED patch by applying your comments.
Regards,
--
Shigeru Hanada