Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Amit Kapila
On Thu, Jan 7, 2016 at 4:21 PM, Andres Freund wrote: > > On 2016-01-07 11:27:13 +0100, Fabien COELHO wrote: > > I read your patch and I know what I want to try to have a small and simple > > fix. I must admit that I have not really understood in which condition the > >

Re: [HACKERS] Speedup twophase transactions

2016-01-09 Thread Simon Riggs
On 9 January 2016 at 12:26, Stas Kelvich wrote: > I’ve updated patch and wrote description of thighs that happens > with 2PC state data in the beginning of the file. I think now this patch > is well documented, > but if somebody points me to places that probably

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Andres Freund
On 2016-01-09 18:04:39 +0530, Amit Kapila wrote: > On Thu, Jan 7, 2016 at 4:21 PM, Andres Freund wrote: > > > > On 2016-01-07 11:27:13 +0100, Fabien COELHO wrote: > > > I read your patch and I know what I want to try to have a small and > simple > > > fix. I must admit that I

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Andres Freund
On 2016-01-07 21:17:32 +0100, Andres Freund wrote: > On 2016-01-07 21:08:10 +0100, Fabien COELHO wrote: > > Hmmm. What I understood is that the workloads that have some performance > > regressions (regressions that I have *not* seen in the many tests I ran) are > > not due to checkpointer IOs, but

Re: [HACKERS] Speedup twophase transactions

2016-01-09 Thread Stas Kelvich
Hi. I’ve updated patch and wrote description of thighs that happens with 2PC state data in the beginning of the file. I think now this patch is well documented, but if somebody points me to places that probably requires more detailed description I’m ready to extend that. 2pc_xlog.diff

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Amit Kapila
On Sat, Jan 9, 2016 at 6:08 PM, Andres Freund wrote: > > On 2016-01-09 18:04:39 +0530, Amit Kapila wrote: > > On Thu, Jan 7, 2016 at 4:21 PM, Andres Freund wrote: > > > > > > On 2016-01-07 11:27:13 +0100, Fabien COELHO wrote: > > > > I read your patch and

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Andres Freund
On 2016-01-09 19:05:54 +0530, Amit Kapila wrote: > Right that won't be acceptable, however I think with your latest > proposal [1] Sure, that'd address that problem. > [...] think that idea will help to mitigate the problem of backend and > bgwriter writes as well. In that, can't we do it with

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Amit Kapila
On Sat, Jan 9, 2016 at 6:26 PM, Andres Freund wrote: > > On 2016-01-09 18:24:01 +0530, Amit Kapila wrote: > > Okay, but I think that is the reason why you are worried that it is possible > > to issue sync_file_range() on a closed file, is that right or am I missing > >

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Andres Freund
On 2016-01-09 18:24:01 +0530, Amit Kapila wrote: > Okay, but I think that is the reason why you are worried that it is possible > to issue sync_file_range() on a closed file, is that right or am I missing > something? That's one potential issue. You can also fsync a different file, try to print

Re: [HACKERS] checkpointer continuous flushing

2016-01-09 Thread Fabien COELHO
Hello Andres, Hm. New theory: The current flush interface does the flushing inside FlushBuffer()->smgrwrite()->mdwrite()->FileWrite()->FlushContextSchedule(). The problem with that is that at that point we (need to) hold a content lock on the buffer! You are worrying that FlushBuffer is

Re: [HACKERS] Speedup twophase transactions

2016-01-09 Thread Simon Riggs
On 9 January 2016 at 12:26, Stas Kelvich wrote: > I’ve updated patch and wrote description of thighs that happens > with 2PC state data in the beginning of the file. I think now this patch > is well documented, > but if somebody points me to places that probably

Re: [HACKERS] [COMMITTERS] pgsql: Blind attempt at a Cygwin fix

2016-01-09 Thread Andrew Dunstan
On 01/08/2016 11:17 AM, Tom Lane wrote: Alvaro Herrera writes: Alvaro Herrera wrote: Obviously this wasn't the best idea ever. Andrew suggests on IM to revert this on Cygwin to just do the "isatty" check as originally. Here's a proposed patch. Thoughts? Ugly,

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

2016-01-09 Thread Artur Zakirov
On 09.01.2016 05:38, Alvaro Herrera wrote: Artur Zakirov wrote: Now almost all dictionaries are loaded into PostgreSQL. But the da_dk dictionary does not load. I see the following error: ERROR: invalid regular expression: quantifier operand invalid CONTEXT: line 439 of configuration file

Re: [HACKERS] pglogical - logical replication contrib module

2016-01-09 Thread Steve Singer
On 12/31/2015 06:34 PM, Petr Jelinek wrote: Hi, I'd like to submit the replication solution which is based on the pglogical_output [1] module (which is obviously needed for this to compile). The pglogical contrib module provides extension which does the master-slave logical replication

Re: [HACKERS] PATCH: Extending the HyperLogLog API a bit

2016-01-09 Thread Tomas Vondra
On 01/01/2016 12:08 AM, Peter Geoghegan wrote: On Thu, Dec 31, 2015 at 12:48 PM, Tomas Vondra wrote: 1) initHyperLogLogError(hyperLogLogState *cState, double error) Instead of specifying bwidth (essentially the number of bits used for addressing in the

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

2016-01-09 Thread Artur Zakirov
Thanks for review. On 09.01.2016 02:04, Alvaro Herrera wrote: Artur Zakirov wrote: --- 74,80 typedef struct aff_struct { ! uint32 flag:16, type:1, flagflags:7,

Re: [HACKERS] [PATCH] Add STRICT to some regression test C functions.

2016-01-09 Thread Tom Lane
Andreas Seltenreich writes: > some of the C functions in the regression test DB readily crash when > passing NULL input values. The regression tests themselves do not pass > NULL values to them, but when the regression database is used as a basis > for fuzz testing, they

Re: [HACKERS] [COMMITTERS] pgsql: Blind attempt at a Cygwin fix

2016-01-09 Thread Michael Paquier
On Sun, Jan 10, 2016 at 2:00 AM, Andrew Dunstan wrote: > I downloaded the official Cygwin packages into a Cygwin instance and checked > how they do things. As I rather expected, they do not use pg_ctl at all to > install or run as a service. Rather, they use the standard

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

2016-01-09 Thread Peter Geoghegan
On Sat, Jan 9, 2016 at 11:02 AM, Tomas Vondra wrote: > So, this seems to bring reasonable speedup, as long as the selectivity is > below 50%, and the data set is sufficiently large. What about semijoins? Apparently they can use bloom filters particularly

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

2016-01-09 Thread Peter Geoghegan
On Sat, Jan 9, 2016 at 4:08 PM, Peter Geoghegan wrote: > Also, have you considered Hash join conditions with multiple > attributes as a special case? I'm thinking of cases like this: Sorry, accidentally fat-fingered my enter key before I was finished drafting that mail. That

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

2016-01-09 Thread Peter Geoghegan
On Sat, Jan 9, 2016 at 11:02 AM, Tomas Vondra wrote: > Which means the "dim.r" column has 100 different values (0-99) with uniform > distribution. So e.g. "WHERE r < 15" matches 15%. I think that the use of a uniform distribution to demonstrate this patch is a bad

[HACKERS] ExecGather() + nworkers

2016-01-09 Thread Peter Geoghegan
The Gather node executor function ExecGather() does this: /* * Register backend workers. We might not get as many as we * requested, or indeed any at all. */ pcxt = node->pei->pcxt; LaunchParallelWorkers(pcxt); /* Set up tuple queue readers to read the results. */

[HACKERS] Spelling corrections

2016-01-09 Thread Peter Geoghegan
Attached patch fixes a couple of misspellings. -- Peter Geoghegan From 1c6149c0ed347d7514104a11bc3b47e1a9a5724a Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Sat, 9 Jan 2016 22:19:49 -0800 Subject: [PATCH] Fix a couple of misspellings ---