On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund wrote:
> The gains are quite noticeable in some cases. So if we can make it work
> without noticeable downsides...
>
> What I'm worried about though is that this, afaics, will quite
> noticeably *increase* total cost in cases with a noticeable number
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 think we can rule out faulty storage
>>>
>>>
>>> Nobody ever expe
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 wo
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. But the evidence points elsewhere i
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 suggestion of making ar
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 do
that when called as
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)
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 written as hardcoded strings
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
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 Terms of Use in
> > http://www.unicod
> 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 value in its binary form as it
>> would be i
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 were exactly compatible with ours, I'd be -1 on
bloating ou
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 CppAsString and CppConcat instead of di
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 case;
this is clearly application driven
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 hereby granted, free of charge, to
On 10/28/16 3:49 PM, Magnus Hagander wrote:
On Fri, Oct 28, 2016 at 2:44 PM, David Steele mailto:da...@pgmasters.net>> 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 symlink.
So that's the
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 that
>> point independent of
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
> ?
There's a comment
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 an empty directory, but
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 pasting into psql's terminal a block of
>> commands enclosed in BEG
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 be feasible to store
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 10
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 he
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 in detail. If you
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 workload)
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 for other types of indexe
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 cost will be alleviated
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 excludes
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 logfile_writename() in write_syslogger_f
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 another contrib module.
> >
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 between the two. The main
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 partitions? If you
>>> haven't, you probably should. (Testi
32 matches
Mail list logo
