Re: [HACKERS] gaussian distribution pgbench

2014-07-13 Thread Mitsumasa KONDO
Hi, 2014-07-04 19:05 GMT+09:00 Andres Freund and...@2ndquadrant.com: On 2014-07-04 11:59:23 +0200, Fabien COELHO wrote: Yea. I certainly disagree with the patch in it's current state because it copies the same 15 lines several times with a two word difference. Independent of whether we

Re: [HACKERS] tweaking NTUP_PER_BUCKET

2014-07-13 Thread Simon Riggs
On 12 July 2014 12:43, Tomas Vondra t...@fuzzy.cz wrote: So lets just this change done and then do more later. There's no way back, sadly. The dense allocation turned into a challenge. I like challenges. I have to solve it or I won't be able to sleep. I admire your tenacity, but how about

Re: [HACKERS] Allowing NOT IN to use ANTI joins

2014-07-13 Thread David Rowley
On Fri, Jul 11, 2014 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: We could no doubt fix this by also insisting that the left-side vars be provably not null, but that's going to make the patch even slower and even less often applicable. I'm feeling discouraged about whether

Re: [HACKERS] Allowing NOT IN to use ANTI joins

2014-07-13 Thread Andres Freund
On 2014-07-13 23:06:15 +1200, David Rowley wrote: I had another look at this and it appears you were right the first time, we need to ensure there's no NULLs on both sides of the join condition. The patch is currently marked as 'ready for committer' - that doesn't seem to correspond to the

Re: [HACKERS] Allowing NOT IN to use ANTI joins

2014-07-13 Thread Tom Lane
David Rowley dgrowle...@gmail.com writes: I had another look at this and it appears you were right the first time, we need to ensure there's no NULLs on both sides of the join condition. Ugh. I'm back to being discouraged about the usefulness of the optimization. The only other way I could

Re: [HACKERS] things I learned from working on memory allocation

2014-07-13 Thread Andres Freund
Hi Robert, On 2014-07-07 15:57:00 -0400, Robert Haas wrote: 1. I tried to write a single allocator which would be better than aset.c in two ways: first, by allowing allocation from dynamic shared memory; and second, by being more memory-efficient than aset.c. Heikki told me at PGCon that he

Re: [HACKERS] tweaking NTUP_PER_BUCKET

2014-07-13 Thread Tomas Vondra
On 13.7.2014 12:27, Simon Riggs wrote: On 12 July 2014 12:43, Tomas Vondra t...@fuzzy.cz wrote: So lets just this change done and then do more later. There's no way back, sadly. The dense allocation turned into a challenge. I like challenges. I have to solve it or I won't be able to

Re: [HACKERS] tweaking NTUP_PER_BUCKET

2014-07-13 Thread Tomas Vondra
On 11.7.2014 19:25, Tomas Vondra wrote: 2) walking through the tuples sequentially -- The other option is not to walk the tuples through buckets, but by walking throught the chunks - we know the tuples are stored as HashJoinTuple/MinimalTuple, so it

Re: [HACKERS] SSL information view

2014-07-13 Thread Stefan Kaltenbrunner
On 07/12/2014 03:08 PM, Magnus Hagander wrote: As an administrator, I find that you fairly often want to know what your current connections are actually using as SSL parameters, and there is currently no other way than gdb to find that out - something we definitely should fix. Yeah that would

Re: [HACKERS] SSL information view

2014-07-13 Thread Magnus Hagander
On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: On 07/12/2014 03:08 PM, Magnus Hagander wrote: As an administrator, I find that you fairly often want to know what your current connections are actually using as SSL parameters, and there is currently no

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

2014-07-13 Thread Tomas Vondra
On 3.7.2014 19:36, Tomas Vondra wrote: On 1.7.2014 01:24, Tomas Vondra wrote: On 30.6.2014 23:12, Tomas Vondra wrote: Hi, Hopefully I got it right this time. At least it seems to be working for cases that failed before (no file leaks, proper rowcounts so far). Attached v7, fixing

Re: [HACKERS] better atomics - v0.5

2014-07-13 Thread Andres Freund
On 2014-07-10 08:46:55 +0530, Amit Kapila wrote: As per my understanding of the general theory around barriers, read and write are defined to avoid reordering due to compiler and full memory barriers are defined to avoid reordering due to processors. No, that's not the case. There's several

Re: [HACKERS] better atomics - v0.5

2014-07-13 Thread Andres Freund
Hi Amit, On 2014-07-08 11:51:14 +0530, Amit Kapila wrote: On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com wrote: On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com wrote: Further review of patch: 1. /* * pg_atomic_test_and_set_flag - TAS() *

Re: [JDBC] [HACKERS] Setting PG-version without recompiling

2014-07-13 Thread Craig Ringer
On 07/03/2014 10:16 PM, Tom Lane wrote: Andreas Joseph Krogh andr...@visena.com writes: Hi. Â I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's minor-version string: 4beta1. Is it possible to set this somewhere without recompiling PG? No, and even if you could,

Re: [HACKERS] tweaking NTUP_PER_BUCKET

2014-07-13 Thread Stephen Frost
Tomas, * Tomas Vondra (t...@fuzzy.cz) wrote: On 6.7.2014 17:57, Stephen Frost wrote: * Tomas Vondra (t...@fuzzy.cz) wrote: I can't find the thread / test cases in the archives. I've found this thread in hackers:

Re: [HACKERS] Use unique index for longer pathkeys.

2014-07-13 Thread Amit Kapila
On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: Hello, This is the continuation from the last CF. This patch intends to make PG to use index for longer pathkeys than index columns when, - The index is a unique index. - All index columns are NOT

Re: [HACKERS] 9.4 documentation: duplicate paragraph in logical decoding example

2014-07-13 Thread Christoph Moench-Tegeder
## Andres Freund (and...@2ndquadrant.com): Care to submit a patch for it Christoph? There it is. Regards, Christoph -- Spare Space diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 41b63b4..6c3707c 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++