Hello, this is the new version of this patch.
At Fri, 26 Feb 2016 13:17:26 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160226.131726.54224488.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, thank you for the comments.
>
> At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakirov
> wrote in
2016-02-25 7:06 GMT+01:00 Catalin Iacob :
> On Fri, Feb 19, 2016 at 9:41 PM, Pavel Stehule
> wrote:
> > It looks like good idea. Last version are not breaking compatibility -
> and
> > I think so it can works.
> >
> > I wrote the code, that works on Python2 and Python3
>
> Hi,
>
> I've attached
I marked this as "ready for commiter" and tried to add me as the
*second* author. But the CF app forces certain msyterious order
for listed names. Is there any means to arrange the author names
in desired order?
At Fri, 26 Feb 2016 16:06:37 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
Hi,
Thanks for your feedback.
On 2016/02/26 0:43, Jean-Pierre Pelletier wrote:
> Why not based it on "Exclusion Constraint" ?
>
> Most discussions as of late seems to focus on Range overlaps which appeal
> (I would think) is that it supports both "equality" and "overlaps", two
> popular partiti
On 26 February 2016 at 13:43, Michael Paquier
wrote:
> > my $caughtup_query = "SELECT '$current_lsn'::pg_lsn <=
> > pg_last_xlog_replay_location()";
> > use
> > my $caughtup_query = "SELECT pg_xlog_location_diff('$current_lsn',
> > pg_last_xlog_replay_location()) <= 0";
> > so it doesn't care if
Hello, This is a (maybe) committer-ready patch of a Tomas
Vondra's project.
This patch applies on the current master and passes make check.
This is to exclude some base-estrict clauses that are implied by
index predicates on index scans on partial indexes.
First, this patch adds a new member ind
On Fri, Feb 26, 2016 at 5:02 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>> We need to be careful here, backward-compatibility is critical for
>> both the client and the server, or to put it in other words, an
>> uptables client should still be able to connect a patched server, and
>> vic
Michael Paquier writes:
> On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut wrote:
>> Tom thought this might require an archive version dump, but I'm not
>> sure. The tags are more of an informational string for human
>> consumption, not strictly part of the archive format.
> Hm, the TOC entry,
"Gabe F. Rudy" writes:
> Is there any way to convince Postgres FDW to leverage the analyze row counts
> or even the "double* totalRowCount" returned from the AcquireSampleRows
> callback from my AnalyzeForeignTable function so that it does not do a
> full-table scan for a COUNT(*) etc?
No. In
On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut wrote:
> On 1/29/16 1:24 AM, Michael Paquier wrote:
>>> I think we should amend the archive tag for these kinds of objects to
>>> > include the table name, so it might look like:
>>> >
>>> > 2153; 2604 39696 DEFAULT public test a rolename
>>> >
>>>
On 2016/02/23 22:51, Robert Haas wrote:
> On Thu, Feb 18, 2016 at 11:11 AM, Amit Langote wrote:
>> Some might think that writing potentially the same PARTITION BY clause 100
>> times for 100 level-1 partitions could be cumbersome. That is what
>> SUBPARTITION BY notation may be good as a shorthand
Hi,
At Thu, 25 Feb 2016 12:22:45 +0100, Tomas Vondra
wrote in <56cee405.30...@2ndquadrant.com>
> >> Attached is a v6 of the patch, which is actually the version
> >> submitted by Kyotaro-san on 2015/10/8 rebased to current master and
> >> with two additional changes.
> >
> > This relies on the f
On Fri, Feb 26, 2016 at 1:47 PM, Craig Ringer wrote:
> On 26 February 2016 at 10:58, Michael Paquier
> wrote:
>> Here is a rebased set after the conflicts created by e640093, with the
>> following changes:
>
> Thanks for rebasing on top of that. Not totally fair when your patch came
> first, but
Hello, this is the second patch plitted out. This allows
multibyte names to be completed in psql.
At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20151106.114717.170526268.horiguchi.kyot...@lab.ntt.co.jp>
> At Thu, 5 Nov 2015 18:32:59 +0900, Amit Langote
>
Hello,
I divided the last patch into one typo-fix patch and one
improvement patch. This is the former one.
At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20151106.114717.170526268.horiguchi.kyot...@lab.ntt.co.jp>
> > Just a minor nitpick -
> >
> > ... ch
On 26 February 2016 at 10:58, Michael Paquier
wrote:
>
> Here is a rebased set after the conflicts created by e640093, with the
> following changes:
>
Thanks for rebasing on top of that. Not totally fair when your patch came
first, but I guess it was simpler to merge the other one first.
> -
Hello, thank you for the comments.
At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakirov
wrote in <56c1c80d.7020...@postgrespro.ru>
> On 05.02.2016 11:09, Kyotaro HORIGUCHI wrote:
> > Hello,
> >
> > I considered how to make tab-completion robust for syntactical
> > noises, in other words, optional w
Hi,
On 02/26/2016 04:32 AM, Mark Dilger wrote:
On Feb 25, 2016, at 4:59 PM, Tomas Vondra wrote:
...
The culprit here is that the two columns are not independent, but
are (rather strongly) correlated due to the way you've generated
the data.
Yes, that was intentional. Your formula is exa
Thank you for pushing this.
At Tue, 16 Feb 2016 15:07:32 +0900, Fujii Masao wrote
in
> > Attached patch uses the above formula for 9.3. I'm thinking to push your
> > patches to 9.2, 9.4, 9.5, master, also push the attached one to 9.3.
> > Comments?
>
> Pushed. Thanks for the report and patches
> On Feb 25, 2016, at 4:59 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> On 02/26/2016 12:16 AM, Mark Dilger wrote:
>>
>> It is not hard to write test cases where your patched version overestimates
>> the number of rows by a very similar factor as the old code underestimates
>> them. My very first t
On Wed, Feb 17, 2016 at 9:52 PM, Michael Paquier
wrote:
> On Fri, Feb 5, 2016 at 4:17 AM, Michael Paquier wrote:
>> Thanks for your enthusiasm. Now, to do an auto-critic of my patch:
>> + if ($params{allows_streaming})
>> + {
>> + print $conf "wal_level = hot_standby\n";
On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs wrote:
> On 24 February 2016 at 23:26, Amit Kapila wrote:
>
>> From past few weeks, we were facing some performance degradation in the
>> read-only performance bench marks in high-end machines. My colleague
>> Mithun, has tried by reverting commit a
At Fri, 26 Feb 2016 10:38:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160226.103822.12680005.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, Thanks for the new patch.
>
>
> At Fri, 26 Feb 2016 08:52:54 +0900, Masahiko Sawada
> wrote in
> > Previous patch could not parse one char
Hello, Thanks for the new patch.
At Fri, 26 Feb 2016 08:52:54 +0900, Masahiko Sawada
wrote in
> Previous patch could not parse one character standby name correctly.
> Attached latest patch.
I haven't looked it in detail but it won't work as you
expected. flex compains as the following for v12
Hi,
On 02/26/2016 12:16 AM, Mark Dilger wrote:
It is not hard to write test cases where your patched version overestimates
the number of rows by a very similar factor as the old code underestimates
them. My very first test, which was not specifically designed to demonstrate
this, happens to be
On 1/29/16 1:24 AM, Michael Paquier wrote:
>> I think we should amend the archive tag for these kinds of objects to
>> > include the table name, so it might look like:
>> >
>> > 2153; 2604 39696 DEFAULT public test a rolename
>> >
>> > Comments?
> +1. I noticed that this limitation is present for t
Thanks, pushed.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
> On Feb 25, 2016, at 3:16 PM, Mark Dilger wrote:
>
>
>> On Feb 23, 2016, at 5:12 PM, Tomas Vondra
>> wrote:
>>
>>
>>
>> So much better. Clearly, there are cases where this will over-estimate the
>> cardinality - for example when the values are somehow correlated.
>>
>
> I applied your
On Fri, Feb 26, 2016 at 1:23 AM, Masahiko Sawada wrote:
> Attached latest patch includes document patch.
>
>> When I changed s_s_names to 'hoge*' and reloaded the configuration file,
>> the server crashed unexpectedly with the following error message.
>> This is obviously a bug.
>
> Fixed.
>
>>
> On Feb 23, 2016, at 5:12 PM, Tomas Vondra
> wrote:
>
>
>
> So much better. Clearly, there are cases where this will over-estimate the
> cardinality - for example when the values are somehow correlated.
>
I applied your patch, which caused a few regression tests to fail. Attached
is a pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/02/2016 23:12, Vik Fearing wrote:
> On 02/25/2016 09:13 PM, Julien Rouhaud wrote:
>> Hello,
>>
>> I just saw that the CREATE OPERATOR CLASS documentation doesn't
>> mention that BRIN indexes also support the STORAGE parameter.
>
> Good catch!
>
On 02/25/2016 09:13 PM, Julien Rouhaud wrote:
> Hello,
>
> I just saw that the CREATE OPERATOR CLASS documentation doesn't mention
> that BRIN indexes also support the STORAGE parameter.
Good catch!
> Patch attached.
I think this is the wrong approach; that parenthetical list now
represents a f
On Fri, Feb 26, 2016 at 1:38 AM, Valery Popov wrote:
> Hi, Michael
>
>
> 23.02.2016 10:17, Michael Paquier пишет:
>>
>> Attached is a set of patches implementing a couple of things that have
>> been discussed, so let's roll in.
>>
>> Those 4 patches are aimed at putting in-core basics for the conc
On Fri, Jan 29, 2016 at 6:15 AM, Teodor Sigaev wrote:
>> The behavior of this function is surprising to me.
>>
>> select substring_similarity('dog' , 'hotdogpound') ;
>>
>> substring_similarity
>> --
>> 0.25
>>
> Substring search was desined to search simil
>
Added to the commitfest 2016-03.
[CF] https://commitfest.postgresql.org/9/540/
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
I just saw that the CREATE OPERATOR CLASS documentation doesn't mention
that BRIN indexes also support the STORAGE parameter.
Patch attached.
Regards
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/create_opclass.sgml b/doc/src/sgml/ref/create_opclas
Michael Paquier writes:
> On Tue, Feb 16, 2016 at 2:45 AM, Robbie Harwood wrote:
>> David Steele writes:
>>> On 2/10/16 4:06 PM, Robbie Harwood wrote:
Hello friends,
For your consideration, here is a new version of GSSAPI encryption
support. For those who prefer, it's also
On Wed, Feb 24, 2016 at 8:51 AM, Teodor Sigaev wrote:
> Thank you for remembering this problem, at least for me.
>
>>> Well, turns out there's a quite significant difference, actually. The
>>> index sizes I get (quite stable after multiple runs):
>>>
>>> 9.5 : 2428 MB
>>> 9.6 + alone clean
On Thu, Feb 11, 2016 at 8:46 AM, Anastasia Lubennikova
wrote:
> 02.02.2016 15:50, Anastasia Lubennikova:
>
> As promised, here's the new version of the patch "including_columns_4.0".
> I fixed all issues except some points mentioned below.
Thanks for the update patch. I get a compiler warning:
On 24 February 2016 at 23:26, Amit Kapila wrote:
> From past few weeks, we were facing some performance degradation in the
> read-only performance bench marks in high-end machines. My colleague
> Mithun, has tried by reverting commit ac1d794 which seems to degrade the
> performance in HEAD on hi
Hey all,
I'm building a FDW around a column-store backend (similar to CStore but for
genomic data!).
I have tables in the billions of rows, and have a common query pattern of
asking for the table size (i.e. SELECT COUNT(*) FROM big_fdw_table; ).
This is a read-optimized system in which I know
Hi,
On 02/25/2016 05:32 PM, Teodor Sigaev wrote:
Well, turns out there's a quite significant difference, actually. The
index sizes I get (quite stable after multiple runs):
9.5 : 2428 MB
9.6 + alone cleanup : 730 MB
9.6 + pending lock : 488 MB
In attach modified alone_cleanup patc
W dniu 11.02.2016 o 14:26, Jacek Wielemborek pisze:
> W dniu 11.02.2016 o 14:06, Rich Jones pisze:
>> Hello, team!
>>
>> I am writing on behalf of the BPGSQL Project [1] to request a code audit
>> from a core PGSQL team member.
>>
>> The current maintainer is worried about the security of the code,
Hi, Michael
23.02.2016 10:17, Michael Paquier пишет:
Attached is a set of patches implementing a couple of things that have
been discussed, so let's roll in.
Those 4 patches are aimed at putting in-core basics for the concept I
call password protocol aging, which is a way to allow multiple
pas
Well, turns out there's a quite significant difference, actually. The
index sizes I get (quite stable after multiple runs):
9.5 : 2428 MB
9.6 + alone cleanup : 730 MB
9.6 + pending lock : 488 MB
In attach modified alone_cleanup patch which doesn't break cleanup process as it
does p
Attached latest patch includes document patch.
> When I changed s_s_names to 'hoge*' and reloaded the configuration file,
> the server crashed unexpectedly with the following error message.
> This is obviously a bug.
Fixed.
> - allows any byte except a double quote in double-quoted
>repres
Why not based it on "Exclusion Constraint" ?
Most discussions as of late seems to focus on Range overlaps
which appeal (I would think) is that it supports both "equality" and
"overlaps",
two popular partitioning schemes.
"Equality" as in "value1 = value2" can be implemented with "range
overlaps"
Why not based it on "Exclusion Constraint" ?
Most discussions as of late seems to focus on Range overlaps which appeal
(I would think) is that it supports both "equality" and "overlaps", two
popular partitioning schemes.
"Equality" as in "value1 = value2" can be implemented with "range
overlaps"
Jim Nasby wrote:
> >Here we have another case. prodesc is a global thing. And it is shared
> >between different operations. Problem was that there is no partcular
> >owner, and we have to wait when last operation which deals with it
> >would finish. It looks like perfect job for reference counting
On 2/25/16 2:08 AM, Michael Paquier wrote:
> On Wed, Feb 24, 2016 at 7:12 PM, Robbie Harwood wrote:
>>
>> Not that I can immediately see. As long as the client and server are
>> both patched, everything should work. My process is the same as with
>> previous versions of this patchset [0], and th
Robert Haas writes:
> On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira >> wrote:
>>> To pass last_syslogger_file_time, we have 2 solutions: 1, add a
>>> global variable to record last_syslogger_file_time which shared by
>>> backends and syslogger, so backends can get last_syslogger_file_time
>>> ver
On Thu, Feb 25, 2016 at 01:53:12PM +0900, Michael Paquier wrote:
> > Well, as far as I know XC doesn't support data redistribution between
> > nodes and I saw good benchmarks of that, as well as XL.
>
> XC does support that in 1.2 with a very basic approach (coded that
> years ago), though it take
Hi,
On 02/25/2016 11:56 AM, Kyotaro HORIGUCHI wrote:
Hello, Tomas. my cerebral cortext gets squeezed by jumping from
parser to planner.
LOL
At Wed, 24 Feb 2016 01:13:22 +0100, Tomas Vondra wrote
in <56ccf5a2.5040...@2ndquadrant.com>
Hi,
On 12/06/2015 11:48 PM, Tomas Vondra wrote:
/
Hello, Tomas. my cerebral cortext gets squeezed by jumping from
parser to planner.
At Wed, 24 Feb 2016 01:13:22 +0100, Tomas Vondra
wrote in <56ccf5a2.5040...@2ndquadrant.com>
> Hi,
>
> On 12/06/2015 11:48 PM, Tomas Vondra wrote:
> >/*
> > * Frequently, there will be no partial indexes,
Hello,
At Wed, 24 Feb 2016 18:01:59 +0900, Masahiko Sawada
wrote in
> On Wed, Feb 24, 2016 at 5:37 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > Ok, I think we should concentrate the parser part for now.
> >
> > At Tue, 23 Feb 2016 17:44:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
>
55 matches
Mail list logo