On Sat, Aug 29, 2020 at 8:06 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > I pushed despite the objection because it seemed that downstream
> > discussion was largely favorable to the change, and there's a different
> > proposal to solve the bloat problem for analyze; and also:
>
> Note that
Alvaro Herrera writes:
> I pushed despite the objection because it seemed that downstream
> discussion was largely favorable to the change, and there's a different
> proposal to solve the bloat problem for analyze; and also:
Note that this quasi-related patch has pretty thoroughly hijacked
the CF
Hi,
On 2020-08-06 18:02:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > In fact using conceptually like a new snapshot for each sample tuple
> > actually seems like it'd be somewhat of an improvement over using a
> > single snapshot.
>
> Dunno, that feels like a fairly bad idea to me. It
On 2020-Aug-05, Andres Freund wrote:
> I'm mildly against that, because I'd really like to start making use of
> the flag. Not so much for cancellations, but to avoid the drastic impact
> analyze has on bloat. In OLTP workloads with big tables, and without
> disabled cost limiting for analyze (or
Robert Haas writes:
> Thinking about it more, there are really two ways to think about an
> estimated row count.
> On the one hand, if you think of the row count estimate as the number
> of rows that are going to pop out of a node, then it's always right to
> think of a unique index as limiting t
On Thu, Aug 6, 2020 at 5:35 PM Tom Lane wrote:
> > It's not clear to me that it would even be correct to categorize those
> > somewhat-different results as "less accurate."
>
> Estimating two rows where the correct answer is one row is clearly
> "less accurate" [ than estimating one row ].
That's
On Thu, 6 Aug 2020 at 22:35, Tom Lane wrote:
> Robert Haas writes:
> > ... how
> > important is stability to ANALYZE? If you *either* retake your MVCC
> > snapshots periodically as you re-scan the table *or* use a non-MVCC
> > snapshot for the scan, you can get those same kinds of artifacts: you
Andres Freund writes:
> In fact using conceptually like a new snapshot for each sample tuple
> actually seems like it'd be somewhat of an improvement over using a
> single snapshot.
Dunno, that feels like a fairly bad idea to me. It seems like it would
overemphasize the behavior of whatever quer
Hi,
On 2020-08-06 16:22:23 -0400, Robert Haas wrote:
> On Thu, Aug 6, 2020 at 3:11 PM Tom Lane wrote:
> > (1) Without a snapshot it's hard to make any non-bogus decisions about
> > which tuples are live and which are dead. Admittedly, with Simon's
> > proposal the final totals would be spongy an
Robert Haas writes:
> ... how
> important is stability to ANALYZE? If you *either* retake your MVCC
> snapshots periodically as you re-scan the table *or* use a non-MVCC
> snapshot for the scan, you can get those same kinds of artifacts: you
> might see two copies of a just-updated row, or none. M
Hi,
On 2020-08-06 14:48:52 -0400, Robert Haas wrote:
> On Thu, Aug 6, 2020 at 2:37 PM Tom Lane wrote:
> > +1 for removal. It's not clear to me that we'd ever put it back.
> > Long-running ANALYZE snapshots are indeed a problem, but Simon's proposal
> > upthread to just take a new one every so of
On Thu, Aug 6, 2020 at 3:11 PM Tom Lane wrote:
> (1) Without a snapshot it's hard to make any non-bogus decisions about
> which tuples are live and which are dead. Admittedly, with Simon's
> proposal the final totals would be spongy anyhow, but at least the
> individual decisions produce meaningf
Robert Haas writes:
> Not to get too far from the proposal on the table of just removing
> something that's been unused for a really long time, which stands on
> its own merits, but if a particular ANALYZE doesn't invoke any
> user-defined functions and isn't run inside a transaction, could we
> s
On Thu, Aug 6, 2020 at 2:37 PM Tom Lane wrote:
> +1 for removal. It's not clear to me that we'd ever put it back.
> Long-running ANALYZE snapshots are indeed a problem, but Simon's proposal
> upthread to just take a new one every so often seems like a much cleaner
> and simpler answer than having
Robert Haas writes:
> On Wed, Aug 5, 2020 at 9:07 PM Andres Freund wrote:
>> Only mildly against because it'd not be hard to reintroduce once we need
>> it.
> I think we should nuke it. It's trivial to reintroduce the flag if we
> need it later, if and when somebody's willing to do the associate
On Wed, Aug 5, 2020 at 9:07 PM Andres Freund wrote:
> I'm mildly against that, because I'd really like to start making use of
> the flag. Not so much for cancellations, but to avoid the drastic impact
> analyze has on bloat. In OLTP workloads with big tables, and without
> disabled cost limiting
On Thu, 6 Aug 2020 at 02:07, Andres Freund wrote:
>
> On 2020-08-05 19:55:49 -0400, Alvaro Herrera wrote:
> > ... which means the flag I had added two days earlier has never been
> > used for anything. We've carried the flag forward to this day for
> > almost 13 years, dutifully turning it on an
Hi,
On 2020-08-05 19:55:49 -0400, Alvaro Herrera wrote:
> Back in the 8.3 cycle (2007) when the autovacuum launcher/worker split
> was done, we annoyed people because it blocked DDL. That led to an
> effort to cancel autovac automatically when that was detected, by Simon
> Riggs.
> https://postgr
18 matches
Mail list logo
