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 expecte
On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas wrote:
> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee 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 ot
On Mon, Sep 19, 2011 at 3:11 PM, Dan McGee 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
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
---
This addresses some of the
On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian 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 "trust"
version, just
as the -B datadir has to be the correct version.
I'm not on the mailing list nor do I have a lot of free time 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
