On Fri, Mar 17, 2017 at 10:00:17AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 03/17/2017 09:30 AM, Robert Haas wrote:
> >> In the department of nitpicks, we usually try to write commit messages
> >> so that the first line is a summary line which stands alone, and then
> >> there's a bl
Andrew Dunstan writes:
> On 03/17/2017 09:30 AM, Robert Haas wrote:
>> In the department of nitpicks, we usually try to write commit messages
>> so that the first line is a summary line which stands alone, and then
>> there's a blank line, and then more follows. a la
>> https://chris.beams.io/pos
On 03/17/2017 09:30 AM, Robert Haas wrote:
>
> In the department of nitpicks, we usually try to write commit messages
> so that the first line is a summary line which stands alone, and then
> there's a blank line, and then more follows. a la
> https://chris.beams.io/posts/git-commit/#separate
>
On Thu, Mar 16, 2017 at 6:39 PM, Andrew Gierth
wrote:
> Avoid having vacuum set reltuples to 0 on non-empty relations in the
> presence of page pins, which leads to serious estimation errors in the
> planner. This particularly affects small heavily-accessed tables,
> especially where locking (e.g
> "Andrew" == Andrew Gierth writes:
Tom> I have not looked very closely, but I'm suspicious that the test
Tom> case depends on no autovacuum transactions running concurrently
Tom> with it. Disabling autovac on the table itself is not enough to
Tom> control whether global xmin is being he
> "Tom" == Tom Lane writes:
Tom> Hm, buildfarm results suggest this test is not entirely stable:
I see it and will work on it.
Tom> I have not looked very closely, but I'm suspicious that the test
Tom> case depends on no autovacuum transactions running concurrently
Tom> with it. Disabl
On 2017-03-16 23:37:06 -0400, Tom Lane wrote:
> Andrew Gierth writes:
> > Avoid having vacuum set reltuples to 0 on non-empty relations in the
> > presence of page pins, which leads to serious estimation errors in the
> > planner.
>
> Hm, buildfarm results suggest this test is not entirely stable
Andrew Gierth writes:
> Avoid having vacuum set reltuples to 0 on non-empty relations in the
> presence of page pins, which leads to serious estimation errors in the
> planner.
Hm, buildfarm results suggest this test is not entirely stable:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm
On Thu, Mar 16, 2017 at 11:39 PM, Andrew Gierth
wrote:
> Avoid having vacuum set reltuples to 0 on non-empty relations in the
> presence of page pins, which leads to serious estimation errors in the
> planner. This particularly affects small heavily-accessed tables,
> especially where locking (e
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
15 matches
Mail list logo
