From: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: contrib/pg_stat_statements |
Date: | 2008-10-28 21:12:17 |
Message-ID: | 49078031.9030002@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ITAGAKI Takahiro wrote:
> It might be possbile to add a queryText field into QueryDesc
> and all of the codes using QueryDesc initialize the field with
> their own query texts, but it requires modifications in many
> different modules and copying query text might be needed.
> I don't want to do it only for this contrib module,
> so I'll support only top statements at the moment. Sorry.
>
Indeed, this turned out to be more difficult than I initally thought.
Nevertheless I still think that tracking nested statements is worth the
effort. Attached is a patch that adds sourceText to QueryDesc (should
apply cleanly after auto_explain.patch). This is very WIP, for one thing
it assumes that the source text pointers can be passed around freely.
But is the idea of extending QueryDesc generally acceptable? Is it OK
to make a copy of the query string?
I tested with modified pg_stat_statements (removed toplevel checks),
and much to my delight it didn't crash immediately :) I've only done
some limited testing but a lot of interesting stuff seems to turns out --
for instance we get to see the lookups generated by referential integrity
checks (could help to identify missing indexes on FK fields).
Regards,
Martin
Attachment | Content-Type | Size |
---|---|---|
querydesc.patch | text/x-diff | 11.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2008-10-28 21:23:57 | Re: Any reason to have heap_(de)formtuple? |
Previous Message | Simon Riggs | 2008-10-28 20:49:52 | Re: Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. |