This is a bit of a corner case in all honesty, but if you have a short
table (under 20 rows), the 10% heuristic used that decides whether
distinct values scale with the row count will result in rather odd
values for stadistinct in pg_statistic, such as '-0.2' or '-0.67',
rather than the
On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee d...@archlinux.org wrote:
[ patch ]
I suppose it's Tom who really needs to comment on this, but I'm not
too enthusiastic about this approach. Duplicating the Linux kernel
This attempts to be as simple as it gets while reducing function call
depth, and should be viewed as a proof of concept. It is also untested
as of now, but will try to do that and report back.
I'm hoping I followed the rabbit hole correctly and are correctly
comparing the right pointers to each
This is one way to prevent the kernel warning message without having to
introduce a new constant. Scale the old oom_adj-style value the same way
the kernel internally does it and use that instead if oom_score_adj is
available for writing.
Signed-off-by: Dan McGee d...@archlinux.org
On Mon, Sep 19, 2011 at 3:11 PM, Dan McGee d...@archlinux.org wrote:
This is one way to prevent the kernel warning message without having to
introduce a new constant. Scale the old oom_adj-style value the same way
the kernel internally does it and use that instead if oom_score_adj is
available
On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian br...@momjian.us wrote:
0003 is what I really wanted to solve, which was my failure with
pg_upgrade. The call to pg_ctl didn't succeed because the binaries
didn't match the data directory, thus resulting in this:
The error had nothing to do with
to keep
up with normal development, but if there are quick things I can do to
get these patches in let me know.
-Dan
From 840bdd22b62c8d45796abf7eb9e7b3da0329dce8 Mon Sep 17 00:00:00 2001
From: Dan McGee d...@archlinux.org
Date: Tue, 21 Jun 2011 18:48:01 -0500
Subject: [PATCH 1/3] pg_upgrade: fix typo
