Hi,
I don't think we should have global view from these functions. Because they're all for housekeeping and monitoring, mainly by DBA, it will be even better to have local view.
I'm now writing XC reference manual derived from that for PG and I found that we can explicitly tell readers that OID is local. I hope this decreases confusion.
I think the problem (pg_class entries and pg_relation_size() function) is separate one from OID unification. Anyway, as you suggested, OID unification takes a bit of resource. I'd like to see feedback from others on this.
Regards;
---
Koichi Suzuki
On Wed, 15 Jun 2011 08:13:17 -0400
Mason <ma...@us...> wrote:
> On Wed, Jun 15, 2011 at 12:20 AM, Koichi Suzuki
> <ko...@in...> wrote:
> > Hi,
> >
> > I'm writing XC reference manual based upon PG reference manual. In performance sections, I need to present EXPLAIN example, reltuples and relpages value from pg_class.
> >
> > Somehow, both reltuples and relpages values are zero both in coordinator datanode. pg_table_size() returns more realistic value. pg_relation_size() returns zero.
> >
> > It is not critical to run regression test and other cases but will be very important if users would like to see what is going on.
> >
> > May need more discussion how to fix it.
> >
>
> One difficulty is for functions that take OID. If we have not unified
> them on the nodes it makes it a little more difficult. We could
> consider ways to do that efficiently. Pavan, Michael and I briefly
> discussed this but arrived at no conclusion. If OIDs were the same
> across all nodes these types of issues may be easier to handle. I
> think there is a case or two where internally the relation name is
> used to deal with this.
>
> It is kind of difficult to ascertain how to handle various pg_catalog
> type of queries. If we pull data from the data nodes for
> pg_relation_size, we will get a more accurate answer. However, for
> other queries, if we try and get a list of relations and we send it
> down to the nodes, we will get duplicates.
>
> In this case here handling could be to find the corresponding
> dbname.schema.relation and map it to a new aggregate
> pg_relation_size(relationname) internally to grab the info from the
> nodes. It can be flagged as a "coordinator" (volatile) function so
> that it does not get pushed down within the main query but is executed
> separately.
>
> Regards,
>
> Mason
>
>
> > Regards;
> > ---
> > Koichi
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
>
ddd
|
