Re: [PATCHES] WIP: executor_hook for pg_stat_statements

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] WIP: executor_hook for pg_stat_statements
Date: 2008-07-08 01:29:04
Message-ID: 20080708091907.6D35.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I don't want the tag there at all, much less converted to a pointer.
> What would the semantics be of copying the node, and why?
>
> Please justify why you must have this and can't do what you want some
> other way.

In my pg_stat_statements plugin, the tag is used to cache hash values of
SQL strings in PlannedStmt. It is not necessarily needed because the hash
value is re-computable from debug_query_string. It is just for avoiding
the work. In addition, we see different SQLs in debug_query_string in
PREPARE/EXECUTE and DECLARE/FETCH. Hashed SQL cache can work on those
commands.

However, it's ok to remove the tag field from the patch if we should
avoid such an unused field in normal use. EXECUTE and FETCH issues
could be solved if I write simple SQL parser in my plugin because SQL
bodies can be fetched from pg_prepared_statements and pg_cursors.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-07-08 01:56:34 Re: CommitFest rules
Previous Message Tom Lane 2008-07-08 01:28:17 Re: 8.1 index corruption woes

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2008-07-08 07:36:21 Re: [HACKERS] Userset logging
Previous Message Simon Riggs 2008-07-07 15:13:13 Userset logging