Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

2015-11-14 Thread Amit Langote
On Tue, Nov 10, 2015 at 5:02 PM, Amit Langote wrote: > On 2015/10/29 23:22, Syed, Rahila wrote: > How about the following instead - > > + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s", > +

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

2015-11-14 Thread Dean Rasheed
On 13 November 2015 at 21:34, Dean Rasheed wrote: > On 13 November 2015 at 18:36, Tom Lane wrote: >> Next question: in the additional range-reduction step you added to ln_var, >> why stop there, ie, what's the rationale for this magic number: >> >>

Re: [HACKERS] Freeze avoidance of very large table.

2015-11-14 Thread Amit Kapila
On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund wrote: > On 2015-10-31 11:02:12 +0530, Amit Kapila wrote: > > On Thu, Oct 8, 2015 at 11:05 PM, Simon Riggs wrote: > > > > > > On 1 October 2015 at 23:30, Josh Berkus wrote: > > >> > > >>

Re: [HACKERS] Parallel Seq Scan

2015-11-14 Thread Amit Kapila
On Fri, Nov 13, 2015 at 11:05 PM, Jeff Janes wrote: > > On Wed, Nov 11, 2015 at 6:53 AM, Robert Haas wrote: > > > > I've committed most of this, except for some planner bits that I > > didn't like, and after a bunch of cleanup. Instead, I committed

Re: [HACKERS] Freeze avoidance of very large table.

2015-11-14 Thread Amit Kapila
On Sat, Nov 14, 2015 at 1:12 AM, Bruce Momjian wrote: > > On Tue, Nov 3, 2015 at 09:03:49AM +0530, Amit Kapila wrote: > > I think in that case we can call it as page info map or page state map, but > > I find retaining visibility map name in this case or for future (if we want

Re: [HACKERS] eXtensible Transaction Manager API

2015-11-14 Thread Craig Ringer
On 13 November 2015 at 21:35, Michael Paquier wrote: > On Tue, Nov 10, 2015 at 3:46 AM, Robert Haas > wrote: > > On Sun, Nov 8, 2015 at 6:35 PM, Michael Paquier > > wrote: > >> Sure. Now imagine that the pg_twophase

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

2015-11-14 Thread Dean Rasheed
On 14 November 2015 at 16:13, Tom Lane wrote: >> We might well want to keep the power-10 argument reduction step, but >> it would now be there purely on performance grounds so there's scope >> for playing around with the threshold at which it kicks in. > > My inclination is to

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

2015-11-14 Thread Craig Ringer
On 14 November 2015 at 15:50, Amit Kapila wrote: > One thing that occurred to me in this context is that if we store the wait > event information in PGPROC, then can we think of providing the info > about wait events in a separate view pg_stat_waits (or

Re: [HACKERS] pg_stat_statements query jumbling question

2015-11-14 Thread Tom Lane
Michael Paquier writes: > On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud > wrote: >> I'm also rather sceptical about this change. > Hm. Thinking a bit about this patch, it presents the advantage to be > able to track the same queries easily

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

2015-11-14 Thread Tom Lane
Dean Rasheed writes: > I'm much less happy with the sqrt() range reduction step though. I now > realise that the whole increment local_rscale before each sqrt() > approach is totally bogus. Yeah, I was wondering about that yesterday ... > So repeated use of sqrt() can

Re: [HACKERS] pg_stat_statements query jumbling question

2015-11-14 Thread Michael Paquier
On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > On 10/10/2015 08:46, Satoshi Nagayasu wrote: >> On 2015/10/03 6:18, Peter Geoghegan wrote: >>> On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu >>>

[HACKERS] dynloader.h missing in prebuilt package for Windows?

2015-11-14 Thread Chapman Flack
Hi, This is my first -hackers message; I've recently been putting some effort into PL/Java since this summer (my employer published a restated IP policy that seems much friendlier toward FOSS contributions on my own time, so my PL/Java contributions will be seen to have ticked up since then).

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

2015-11-14 Thread Tom Lane
Chapman Flack writes: > Ken Olson has helped me greatly by testing on Windows, and he noticed > something odd: #include fails on Windows when building > an extension out-of-tree, simply because that file isn't there. While it may indeed be a packaging bug that that file

Re: [HACKERS] Python 3 compatibility fun

2015-11-14 Thread Peter Eisentraut
On 11/11/15 1:49 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 11/11/15 12:08 PM, Tom Lane wrote: >>> we're failing to build against Python 3.5 because the python guys >>> have randomly changed some error message texts, again. > >> This has already been fixed in the 9.5.

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

2015-11-14 Thread Tom Lane
Dean Rasheed writes: > Yeah, that makes sense. Thinking about it some more, its potential > benefit becomes even less apparent at higher rscales because the cost > of ln() relative to sqrt() will become larger -- the number of Taylor > series terms required will grow

Re: [HACKERS] RLS and LEAKPROOF functions

2015-11-14 Thread Noah Misch
On Tue, Aug 11, 2015 at 09:27:17AM -0500, Ted Toth wrote: > I built an index on a jsonb column of a table with RLS enabled but it > was not being used. Turns out the the function jsonb_contains needed > to be LEAKPROOF (thanks Joe Conway). However I do not actually know if > jsonb_contains is

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

2015-11-14 Thread Chapman Flack
On 11/14/15 18:18, Tom Lane wrote: > While it may indeed be a packaging bug that that file isn't installed, > the reason why nobody noticed before is that there doesn't seem to be > any good reason for anything except dfmgr.c to include it. What's the > context? One of the most long-standing

Re: [HACKERS] proposal: multiple psql option -c

2015-11-14 Thread Andrew Dunstan
On 11/13/2015 03:54 PM, Catalin Iacob wrote: So my proposal is: allow a *single* argument for -C and treat its content *exactly* like the input from stdin or from a file. That seems to me to get rid of the main motivation for this change, which is to allow multiple such arguments, which