Re: Call flow of btinsert(PG_FUNCTION_ARGS) - Mailing list pgsql-hackers
From | Craig Ringer |
---|---|
Subject | Re: Call flow of btinsert(PG_FUNCTION_ARGS) |
Date | |
Msg-id | 528B42FF.6050101@2ndquadrant.com Whole thread Raw |
In response to | Call flow of btinsert(PG_FUNCTION_ARGS) (Rohit Goyal <rhtgyl.87@gmail.com>) |
Responses |
Re: Call flow of btinsert(PG_FUNCTION_ARGS)
|
List | pgsql-hackers |
On 11/19/2013 06:22 PM, Rohit Goyal wrote: > Hi All, > > I was reading b tree index code and I wanted to the know the calling > function which calls btinsert > <http://doxygen.postgresql.org/nbtree_8c.html#a2b69e4abd6e38fbb317a503b8cf6e00a>(PG_FUNCTION_ARGS > <http://doxygen.postgresql.org/fmgr_8h.html#adf4dec9b7d23f1b4c68477affde8b7ff>) > function in nbtree.c file. It's specified as a member of the btree index access method in include/catalog/pg_am.h . All invocations are done via index access method lookups; see the documentation for pg_catalog.pg_am, index access methods, etc. It's all abstracted so the core code doesn't know or care whether it's using a b-tree, GiST, or something completely different. Relevant lines: $ git grep '\<btinsert\>' backend/access/nbtree/nbtree.c:btinsert(PG_FUNCTION_ARGS) include/catalog/pg_am.h:DATA(insert OID = 403 ( btree 5 2 t f t t t t t t f t t 0 btinsert btbeginscan btgettuple btgetbitmap btrescan btendscan btmarkpos btrestrpos btbuild btbuildempty btbulkdelete btvacuumcleanup btcanreturn btcostestimate btoptions )); include/catalog/pg_proc.h:DATA(insert OID = 331 ( btinsert PGNSP PGUID 12 1 0 0 0 f f f f t f v 6 0 16 "2281 2281 22812281 2281 2281" _null_ _null_ _null_ _null_ btinsert _null_ _null_ _null_ )); See http://www.postgresql.org/docs/current/static/catalog-pg-am.html In psql: regress=> \x regress=> select * from pg_am where amname = 'btree'; -[ RECORD 1 ]---+---------------- amname | btree ... snip ... aminsert | btinsert ambeginscan | btbeginscan ... snip ... pg_catalog.pg_index rows refer to a vector of pg_opclass rows, one per index column, and that in turns refers to pg_am via the opcmethod column. http://www.postgresql.org/docs/current/static/catalog-pg-index.html http://www.postgresql.org/docs/current/static/catalog-pg-am.html http://www.postgresql.org/docs/current/static/catalog-pg-opclass.html See: This query demonstrates the relationship. It'd be smarter to properly separate out each column but I couldn't be bothered, so it just prints one row per index column in multicolumn indexes, not preserving order. regress=> select c.relname, oc.opcname, am.amname, am.aminsert from pg_index i inner join pg_class c on (i.indexrelid = c.oid) inner join pg_opclass oc ON (oc.oid = ANY(i.indclass)) inner join pg_am am ON (oc.opcmethod = am.oid); All the executor knows is how to ask, eg "for this column of this index, what opclass was specified, and for that opclass, what is the oid of the function to perform the insert access-method operation". It has no idea it's calling btinsert. Try creating a GiST or GIN index and compare. It might help clarify things. > I want to understand the code flow for b tree index It'll take time, but stepping/jumping through it with a debugger will probably be a good way to do that. Connect a psql session, run "SELECT pg_backend_pid()", attach gdb to that pid, set breakpoints at the entry points of interest, cont, then run a command in psql that'll trigger one of the breakpoints. From there you can step through and watch what it does, using "next" to skip over function invocations you aren't interested in and "step" to enter ones you are. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
pgsql-hackers by date: