Re: How to get cursor query
От | Adrian Klaver |
---|---|
Тема | Re: How to get cursor query |
Дата | |
Msg-id | 55D34058.7080200@aklaver.com обсуждение исходный текст |
Ответ на | Re: How to get cursor query (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On 08/18/2015 07:11 AM, Tom Lane wrote: > Adrian Klaver <adrian.klaver@aklaver.com> writes: >> On 08/18/2015 06:44 AM, Tom Lane wrote: >>> Adrian Klaver <adrian.klaver@aklaver.com> writes: >>>> The only thing I can think to do is load pg_stat_statements: >>>> http://www.postgresql.org/docs/9.4/interactive/pgstatstatements.html > >>> That won't help after-the-fact either. > >> Well at some point the query will leave the view, but by default >> pg_stat_statements tracks the last 5000 distinct statements, so you have >> some time > 0 to find it. > > No, you don't have any time to find it, because pg_stat_statements can > only track operations in backends that it's already been loaded into. I was not clear enough. The intent was for the OP to load pg_stat_statements into the remote server and just leave it running. At that point you have something that replicates(to a degree) log_statement = 'all' in postgresql.conf without having to remember to turn it on or off. It imposes an overhead, but that is the case for anything that tracks history. It up to the user to decide whether the benefit is worth the cost. > What's more, it requires shared memory that can only be allocated at > postmaster start, so that there's really no way to load it without a > postmaster restart. > > regards, tom lane > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: