Re: keeping a timestamp of the last stats reset (for a db, table and function)

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: tv(at)fuzzy(dot)cz
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: keeping a timestamp of the last stats reset (for a db, table and function)
Date: 2011-01-04 12:05:16
Message-ID: 4D230CFC.2030205@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

tv(at)fuzzy(dot)cz wrote:
> - I really am not sure about the changes made in pg_proc.h. I'm not sure
> how to assign OIDs to the new functions (I've simply chosen values that
> are were not used in this file), and I'm not sure about the other columns
> (I've copied and modified another function with the same parameter/return
> types)
>

The description of the columns is at the beginning of pg_proc.h, the
part that begins with CATALOG(pg_proc,1255)... The descriptions of some
of the first 11 fields are mostly straighforward. The first fun part is
that how may times the information expected in the second "VARIABLE
LENGTH FIELDS" section repeats varies based on the parameters listed.
The other thing that's usually confusing is that the types for the
values are all expressed as type OID numbers. For example, if you see
"25", that's the OID of the "text" type. You can see the whole list with:

select oid,typname from pg_type;

And if you go back to the file with that list in handle, a lot more of
it should make sense. If you see a multiple parameter type list like
"23 21", that's a function whose input values are of types (int4,int2),

As for getting a new OID, if you go into src/include/catalog/ and run
the unused_oids script, it will give you some help in figuring which
have been used and which not. It's not worth getting too stressed about
the number you choose in the patch submission, because commits between
when you got your free number and when your patch is considered for
commit can make your choice worthless anyway. There's a process
referred to as "catversion bump", where the database catalog version get
updated to reflect things like new pg_proc information, that committers
take care of as one of the last adjustments before final commit. Doing
a final correction to the OID choice is a part every committer knows to
look at.

I wrote a talk that covered some additional trivia in this area, as well
as other things people tend to get confused about in the source code,
that you can find at
http://www.pgcon.org/2010/schedule/attachments/142_HackingWithUDFs.pdf ;
that might be helpful for some other things you might wonder about
eventually.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2011-01-04 12:08:56 Re: regclass without error?
Previous Message Kevin Grittner 2011-01-04 12:04:48 Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid