From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: snapshots in analyze |
Date: | 2015-10-31 16:58:34 |
Message-ID: | 20151031165834.GB24166@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-10-31 12:52:44 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Another angle would be trying to reduce the effects of longrunning
> > transaction. Right now holding a snapshot open for 100 seconds results
> > in profiles like this: ...
> > which is pretty extreme. It's not such a seldom thing to hold a snapshot
> > (e.g. pg_dump...) open for a while.
>
> Yeah. I'm afraid blaming ANALYZE for this is just shooting the messenger.
> Even in a mostly-OLTP workload there are going to be some long-running
> queries, for reporting or whatever. I think we need to focus on how we
> can improve that situation in general, rather than inserting kluges into
> ANALYZE (or pg_dump).
I think we might want to do both. It'd obviously would be of great value
to handle longrunning transactions better. But even if we had an
implementation that knew exactly which rows are not visible to anyone, a
big if, such a longrunning transaction would still at least cause bloat
up to a factor of two (with just one longrunning xact).
Sure pg_dump and analytics queries do so as well, but the user actually
has control over these and can schedule them at opportune times, use
base backups and/or hot standby replicas.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2015-10-31 17:03:58 | Re: pg_stat_statements query jumbling question |
Previous Message | Marko Tiikkaja | 2015-10-31 16:53:54 | Re: September 2015 Commitfest |