| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: On-demand running query plans using auto_explain and signals |
| Date: | 2015-10-15 13:42:47 |
| Message-ID: | 32603.1444916567@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> I was thinking about this and what seems to be the biggest problem is when
> to actually turn the feature on. It seems unlikely that someone will want
> to enable it unconditionally. Enabling per-backend also doesn't seem to be
> a good approach because you don't know if the next query you'd like to look
> at is going to run in this exact backend.
Check.
> What might be actually usable is poking pg_stat_statements for queryid to
> decide if we need to do explain (and possibly analyze).
Hm, interesting thought.
> Does this make sense to you? Does this make a good argument for merging
> pg_stat_statements and auto_explain into core?
I'd say more that it's a good argument for moving this feature out to
one of those extensions, or perhaps building a third extension that
depends on both of those. TBH, none of this stuff smells to me like
something that ought to be in core.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Golub | 2015-10-15 13:44:05 | Re: Database schema diff |
| Previous Message | Robert Haas | 2015-10-15 13:22:32 | Re: Parallel Seq Scan |