Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 02:04 PM, Tom Lane wrote: Comments, better ideas? My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

On 10/28/2016 03:14 PM, Tom Lane wrote: Andrew Dunstan writes: My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it than my

[HACKERS] Speed of user-defined aggregates using array_append as transfn

I looked into this complaint: https://www.postgresql.org/message-id/1477487162344-5927751.p...@n3.nabble.com which boils down to array_append being a lot slower in 9.5 & up than it was before. Now, using array_append as an aggregate transfn has never been a very good idea, because it's inherently

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

Andrew Dunstan writes: > My initial admittedly ugly thought was why not have a second append > function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it than my suggestion of making array_append itself

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

On Fri, 28 Oct 2016 10:03:37 +0200 Gilles Darold wrote: > ... > the v9 of the patch, attached here. I notice that there are a number of user-supplied GUC values for log_destination that are repeatedly used, both in the GUC code and in your patch. These are presently

Re: [HACKERS] Fast Default WIP patch for discussion

> On Oct 28, 2016, at 5:46 AM, Robert Haas wrote: > > On Fri, Oct 21, 2016 at 7:15 PM, Serge Rielau wrote: >> Some key design points requiring discussion: >> 1. Storage of the “exist” (working name) default >> Right now the patch stores the default

Re: [HACKERS] Radix tree for character conversion

On Fri, Oct 28, 2016 at 09:18:08AM -0400, Robert Haas wrote: > On Thu, Oct 27, 2016 at 3:23 AM, Kyotaro HORIGUCHI > wrote: > > | COPYRIGHT AND PERMISSION NOTICE > > | > > | Copyright (c) 1991-2016 Unicode, Inc. All rights reserved. > > | Distributed under the

Re: [HACKERS] emergency outage requiring database restart

On 10/28/16 8:23 AM, Merlin Moncure wrote: On Thu, Oct 27, 2016 at 6:39 PM, Greg Stark wrote: On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote: I think we can rule out faulty storage Nobody ever expects the faulty storage LOL Believe me, I know.

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

I wrote: > 3. We could try to fix it mostly from array_append's side, by teaching it > to return the expanded array in the aggregation context when it's being > called as an aggregate function, and making some > hopefully-not-performance-killing tweaks to nodeAgg to play along with > that. This

Re: [HACKERS] emergency outage requiring database restart

On Fri, Oct 28, 2016 at 3:16 PM, Jim Nasby wrote: > On 10/28/16 8:23 AM, Merlin Moncure wrote: >> >> On Thu, Oct 27, 2016 at 6:39 PM, Greg Stark wrote: >>> >>> On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure >>> wrote: I

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Oct 27, 2016 at 7:38 PM, Michael Paquier wrote: >> I committed and back-patched this with some additional work on the >> comments, but I don't understand this remark. That comment seems like >> it should refer to the checkpointer in modern branches, but isn't

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On 10/28/16 3:49 PM, Magnus Hagander wrote: On Fri, Oct 28, 2016 at 2:44 PM, David Steele > wrote: The patch looks sane to me, but I think it would be good to backpatch the TAP test from the exclusion patch that tests pg_replslot as a

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Oct 18, 2016 at 9:09 PM, Robert Haas wrote: > On Fri, Oct 14, 2016 at 12:37 AM, Ashutosh Bapat > wrote: >>> Have you tested the effect of this patch on planner memory consumption >>> with multi-way joins between tables with many

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

Le 28/10/2016 à 05:09, Karl O. Pinc a écrit : > Hi Gilles, > > On Thu, 27 Oct 2016 19:03:11 +0200 > Gilles Darold wrote: > >> The current v8 of the patch > For your consideration. > > Attached is a patch to apply to v8 of your patch. > > I moved the call to

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On 2016-10-28 11:23:22 +0530, Amit Kapila wrote: > On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund wrote: > > What I'm worried about though is that this, afaics, will quite > > noticeably *increase* total cost in cases with a noticeable number of > > columns and a not that

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Fri, Oct 28, 2016 at 1:45 AM, Jim Nasby wrote: > On 10/27/16 6:39 AM, Mithun Cy wrote: >> >> # pg_autoprewarm. > > > IMO it would be better to add this functionality to pg_prewarm instead of > creating another contrib module. > There is not much common functionality

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 2016-10-28 12:59:58 +0530, Amit Kapila wrote: > On Fri, Oct 28, 2016 at 1:45 AM, Jim Nasby wrote: > > On 10/27/16 6:39 AM, Mithun Cy wrote: > >> > >> # pg_autoprewarm. > > > > > > IMO it would be better to add this functionality to pg_prewarm instead of > > creating

Re: [HACKERS] WAL consistency check facility

On Thu, Oct 27, 2016 at 5:08 PM, Michael Paquier wrote: > On Thu, Sep 29, 2016 at 12:49 PM, Michael Paquier > wrote: >> Seeing nothing happening, I have moved the patch to next CF as there >> is a new version, but no reviews for it. > > Just

[HACKERS] Streaming basebackups vs pg_stat_tmp

In 9.6 and earlier, if you change pg_stat_tmp to be a symlink, basebackups no longer work. That's because we create symlink entry in the tarfile for it instead of an empty directory, but with no data, which Breaks Everything (TM). This was fixed in head in 6ad8ac60, which introduced "more

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Fri, Oct 28, 2016 at 12:16 PM, Andres Freund wrote: > On 2016-10-28 11:23:22 +0530, Amit Kapila wrote: > >> I think if we decide to form the scan key from a qual only when qual >> refers to fixed length column and that column is before any varlen >> column, the increased

Re: [HACKERS] emergency outage requiring database restart

On Thu, Oct 27, 2016 at 6:39 PM, Greg Stark wrote: > On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote: >> I think we can rule out faulty storage > > Nobody ever expects the faulty storage Believe me, I know. But the evidence points elsewhere in this

Re: [HACKERS] Radix tree for character conversion

On Thu, Oct 27, 2016 at 3:23 AM, Kyotaro HORIGUCHI wrote: > | COPYRIGHT AND PERMISSION NOTICE > | > | Copyright (c) 1991-2016 Unicode, Inc. All rights reserved. > | Distributed under the Terms of Use in http://www.unicode.org/copyright.html. > | > | Permission is

Re: [HACKERS] save redundant code for pseudotype I/O functions

Peter Eisentraut writes: > On 10/27/16 11:49 PM, Peter Eisentraut wrote: >> Here is a patch to refactor some of the I/O functions in pseudotypes.c >> to save redundant code and reduce the number of distinct translatable >> strings. Would it be better to use

Re: [HACKERS] Radix tree for character conversion

Robert Haas writes: > On Thu, Oct 27, 2016 at 3:23 AM, Kyotaro HORIGUCHI > wrote: >> Perhaps we can put the files into our repositoy by providing some >> notifications. > Uggh, I don't much like advertising clauses. Even if the license

Re: [HACKERS] Microvacuum support for Hash Index

On Mon, Oct 24, 2016 at 2:21 PM, Ashutosh Sharma wrote: > Hi All, > > I have added a microvacuum support for hash index access method and > attached is the v1 patch for the same. > This is an important functionality for hash index as we already do have same functionality

[HACKERS] JIT compiler for expressions

Hello hackers, We'd like to present our work on adding LLVM JIT compilation of expressions in SQL queries for PostgreSQL. The source code (based on 9.6.1) along with brief manual is available at our github: https://github.com/ispras/postgres . Сurrent speedup for TPC-H Q1 is 20% (on 40GB

Re: [HACKERS] Fast Default WIP patch for discussion

On Wed, Oct 26, 2016 at 11:43 AM, Serge Rielau wrote: > Posting to this group on a Friday evening was obviously a Bad Idea(tm). :-) Not really. It's just that complex patches often don't get an immediate response because people are too busy to look at them and think about them

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On 10/28/16 11:53 AM, Magnus Hagander wrote: In 9.6 and earlier, if you change pg_stat_tmp to be a symlink, basebackups no longer work. That's because we create symlink entry in the tarfile for it instead of an empty directory, but with no data, which Breaks Everything (TM). This was fixed in

Re: [HACKERS] Fast Default WIP patch for discussion

On Fri, Oct 21, 2016 at 7:15 PM, Serge Rielau wrote: > Some key design points requiring discussion: > 1. Storage of the “exist” (working name) default >Right now the patch stores the default value in its binary form as it > would be in the tuple into a BYTEA. >It would

[HACKERS] Overlook in 2bd9e412?

It looks like pq_putmessage_hook and pq_flush_hook were meant for development purpose and not supposed to be committed. Attached patch remove them. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h index 18052cb..5fac817

Re: [HACKERS] Danger of automatic connection reset in psql

On Thu, Oct 20, 2016 at 5:25 PM, Oleksandr Shulgin wrote: > On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin > wrote: >> >> >> Since this is already an improvement, I'm attaching a patch. >> >> If on the other hand, someone is

Re: [HACKERS] Streaming basebackups vs pg_stat_tmp

On Fri, Oct 28, 2016 at 2:44 PM, David Steele wrote: > On 10/28/16 11:53 AM, Magnus Hagander wrote: > >> In 9.6 and earlier, if you change pg_stat_tmp to be a symlink, >> basebackups no longer work. That's because we create symlink entry in >> the tarfile for it instead of

Re: [HACKERS] Query regarding selectDumpableExtension()

On Thu, Oct 27, 2016 at 2:11 AM, amul sul wrote: > selectDumpableExtension() function skip > s dump of > built-in extensions in case of binary-upgrade only, > why not in normal > dump > ? > Can't we assume those will already be installed in the target database > at restore > ?