From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Rohit Goyal <rhtgyl(dot)87(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Call flow of btinsert(PG_FUNCTION_ARGS) |
Date: | 2013-11-19 10:52:47 |
Message-ID: | 528B42FF.6050101@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 2281 2281 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
From | Date | Subject | |
---|---|---|---|
Next Message | Wim Dumon | 2013-11-19 10:55:32 | Re: Windows build patch |
Previous Message | Amit Langote | 2013-11-19 10:45:12 | Re: Call flow of btinsert(PG_FUNCTION_ARGS) |