Re: [HACKERS] add more NLS to bin

On Thu, Oct 27, 2016 at 10:02 AM, Peter Eisentraut wrote: > Here is a series of patches to add NLS to the remaining bin programs, > which were moved from contrib a while ago. (If you're missing pgbench, > I'm skipping that for now because it's more complicated.)

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 8 April 2016 at 06:49, Tom Lane wrote: > David Rowley writes: > Just had a thought about this, which should have crystallized a long > time ago perhaps. Where I'd originally imagined you were going with > this idea is to do what the thread

Re: [HACKERS] commit fest manager for CF 2016-11?

On Mon, Oct 31, 2016 at 1:49 PM, Peter Eisentraut wrote: > Commit fest CF 2016-11 is supposed to start in about a day. I don't > think a commit fest manager was chosen yet. Volunteers? I'd like to pass my turn on this one as CFM, but I can bring in some time

[HACKERS] commit fest manager for CF 2016-11?

Commit fest CF 2016-11 is supposed to start in about a day. I don't think a commit fest manager was chosen yet. Volunteers? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing

Re: [HACKERS] Microvacuum support for Hash Index

Hi Amit, Thanks for showing your interest and reviewing my patch. I have started looking into your review comments. I will share the updated patch in a day or two. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com On Fri, Oct 28, 2016 at 4:42 PM, Amit Kapila

Re: [HACKERS] make coverage-html on OS X

On 10/29/16 3:31 PM, Jim Nasby wrote: tl;dr: It's critical that you actually do a make install, or at least it is if you've set --prefix with configure. If you don't, then even if you do make check you'le going to get the *installed* libpq, and not the *built* libpq. Actually, sometimes that

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 10/30/16 1:32 PM, Tomas Vondra wrote: Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's some sort of CPU / OS scheduling artifact. For example, the system has 36 physical cores, 72 virtual ones (thanks to HT). I find it strange that the "good" client counts are always

Re: [HACKERS] sequential scan result order vs performance

On 10/30/16 9:12 AM, Tom Lane wrote: I think there will be a lot of howls. People expect that creating a table by inserting a bunch of rows, and then reading back those rows, will not change the order. We already futzed with that guarantee a bit with syncscans, but that only affects quite

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, On Sat, 29 Oct 2016 22:00:08 +0200 Gilles Darold wrote: > The attached v10 of the current_logfiles patch Attached is a patch to apply on top of the v10 patch. It updates current_logfiles only once per log rotation. I see no reason to open and write the

Re: [HACKERS] Radix tree for character conversion

Hello, At Fri, 28 Oct 2016 09:42:25 -0400, Tom Lane wrote in <13049.1477662...@sss.pgh.pa.us> > Robert Haas writes: > > On Thu, Oct 27, 2016 at 3:23 AM, Kyotaro HORIGUCHI > > wrote: > >> Perhaps we can put the files

Re: [HACKERS] Logical Replication WIP

On 10/24/2016 09:22 AM, Petr Jelinek wrote: Hi, attached is updated version of the patch. There are quite a few improvements and restructuring, I fixed all the bugs and basically everything that came up from the reviews and was agreed on. There are still couple of things missing, ie column

Re: [HACKERS] sources.sgml typo

>> In doc/src/sgml/sources.sgml: >> >> When the definition an inline function references symbols >> (i.e. variables, functions) that are only available as part of the >> backend, the function may not be visible when included from frontend >> code. >> >> Shinichi Matsuda reported that there

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

Hi, On 10/27/2016 01:44 PM, Amit Kapila wrote: On Thu, Oct 27, 2016 at 4:15 AM, Tomas Vondra wrote: FWIW I plan to run the same test with logged tables - if it shows similar regression, I'll be much more worried, because that's a fairly typical scenario (logged

Re: [HACKERS] [sqlsmith] Missing CHECK_FOR_INTERRUPTS in tsquery_rewrite

I wrote: > Also, I think this is outright *wrong* for phrase search --- dropping some > of the child nodes without any other adjustment isn't valid is it? After further digging, it seems there's no bug because the tree is originally binary and QTNTernary won't try to flatten OP_PHRASE nodes. So

Re: [HACKERS] [sqlsmith] Missing CHECK_FOR_INTERRUPTS in tsquery_rewrite

Andreas Seltenreich writes: > testing with sqlsmith yielded an uncancellable backend hogging CPU time. > Gdb showed it was busy in findeq() of tsquery_rewrite.c. This function > appears to have exponential complexity wrt. the size of the involved > tsqueries. The following

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Oct 2, 2016 at 11:20 PM, Michael Paquier wrote: > On Sat, Sep 10, 2016 at 7:28 AM, Kevin Grittner wrote: >> v6 fixes recently-introduced bit-rot. > > Not as big as I thought, only 2k when both patches are combined... The > patch without noapi

Re: [HACKERS] sequential scan result order vs performance

Andres Freund writes: > It's quite easy to change iteration so we start with the latest item, > and iterate till the first, rather than the other way round. In > benchmarks with somewhat wide columns and aggregation, this yields > speedups of over 30%, before hitting other

Re: [HACKERS] sources.sgml typo

On 2016-10-30 21:30:45 +0900, Tatsuo Ishii wrote: > In doc/src/sgml/sources.sgml: > > When the definition an inline function references symbols > (i.e. variables, functions) that are only available as part of the > backend, the function may not be visible when included from frontend > code. > >

[HACKERS] sources.sgml typo

In doc/src/sgml/sources.sgml: When the definition an inline function references symbols (i.e. variables, functions) that are only available as part of the backend, the function may not be visible when included from frontend code. Shinichi Matsuda reported that there should be "of" between

Re: [HACKERS] Mention column name in error messages

On Sun, Oct 30, 2016 at 12:04 AM, Michael Paquier wrote: > > Okay, so I have reworked the patch a bit and finished with the > attached, adapting the context message to give more information. I > have noticed as well a bug in the patch: the context callback was set >

Re: [HACKERS] JIT compiler for expressions

Hi , On 2016-10-28 14:47:35 +0300, Dmitry Melnik wrote: > We'd like to present our work on adding LLVM JIT compilation of expressions > in SQL queries for PostgreSQL. Great! I'm also working in the area, albeit with a, I think, a bit different approach[1]. Is your goal to integrate this work

Re: [HACKERS] sequential scan result order vs performance

Hi, On 2016-10-30 00:36:55 -0700, Andres Freund wrote: > It's quite easy to change iteration so we start with the latest item, > and iterate till the first, rather than the other way round. In > benchmarks with somewhat wide columns and aggregation, this yields > speedups of over 30%, before

Re: [HACKERS] JIT compiler for expressions

This sounds amazing. My only comment is that LLVM 3.7 is kind of old in the accelerated world of LLVM. If you have patches to LLVM you need you won't have much success submitting them as patches on 3.7. The current stable release is 3.9 and the development snapshots are 4.0. I know LLVM moves

[HACKERS] sequential scan result order vs performance

Hi, while working on the executor, to process "batches" or "bubbles" of tuples I hit some weird performance issues (as in things didn't improve as much as I had hoped). A fair amount of headscratching later I figured out that the tuple order in sequential scans is a major bottleneck. When

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, 28 Jun 2016 11:06:24 +0200 Gilles Darold wrote: > Le 07/04/2016 08:30, Karl O. Pinc a écrit : > > "src/backend/postmaster/syslogger.c expects to see fopen() fail > > with > ENFILE and EMFILE. What will you do if you get these?" > > - Nothing, if the

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Sat, 29 Oct 2016 22:00:08 +0200 Gilles Darold wrote: > The attached v10 of the current_logfiles patch include your last > changes on documentation but not the patch on v9 about the > user-supplied GUC value. I think the v10 path is ready for committers > and that the