On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas wrote:
>
> On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
> wrote:
> > On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > wrote:
> >> So far as I can tell, there are three patches in flight here:
> >>
> >> * replicati
On 30 Jan 2016 8:27 am, "Greg Stark" wrote:
>
>
> On 29 Jan 2016 11:58 pm, "Robert Haas" wrote:
> > It
> > seems pretty easy to construct cases where this technique regresses,
> > and a large percentage of those cases are precisely those where
> > replacement selection would have produced a singl
On 29 Jan 2016 11:58 pm, "Robert Haas" wrote:
> It
> seems pretty easy to construct cases where this technique regresses,
> and a large percentage of those cases are precisely those where
> replacement selection would have produced a single run, avoiding the
> merge step altogether.
Now that avoi
On Fri, Jan 29, 2016 at 2:58 PM, Robert Haas wrote:
> I don't quite know what you mean by these numbers. Add a generic,
> conservative threshold to what?
I meant use "quicksort with spillover" simply because an estimated
90%+ of all tuples have already been consumed. Don't consider the
tuple wid
On Fri, Jan 29, 2016 at 6:55 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> Also couple of minor comments from me.
>
> I think this
>
> + StrNCpy(LWLockTrancheRequestArray[LWLockTrancheRequestsCount].tranche_name,
>> tranche_name, strlen(tranche_name) + 1);
>
>
> should be
>
> + Str
On Fri, Jan 29, 2016 at 6:21 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Jan 4, 2016 at 5:58 PM, Robert Haas wrote:
>
>> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
>> wrote:
>> > If we do that way, then user of API needs to maintain the interlock
>> > guarantee that the
On Thu, Jan 28, 2016 at 11:12:15AM -0500, Robert Haas wrote:
> I'm honestly failing to understand why we should change anything at
> all. I don't believe that doing something more severe than marking
> the portal failed actually improves anything. I suppose if I had to
> pick between what you pro
On Fri, Jan 29, 2016 at 11:41 PM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
>> wrote:
>>
On 1/22/16 12:14 PM, Andres Freund wrote:
On 2016-01-22 08:40:28 -0600, Jim Nasby wrote:
Ideally reviewers shouldn't be doing any testing, because the tests
that are part of the patch should answer every question they would
have, but I don't see that happening until we have a separate
automation
Joshua D. Drake wrote:
> I think the best question to ask is:
>
> "What is the problem we are trying to solve?"
The problem is alluring more patch reviewers, beta testers and bug
reporters. One of the offers is to credit them (I'm not exactly clear
on what is the group to benefit from this, but
On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote:
> Alexander Korotkov writes:
>> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera
>> wrote:
>>> I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something
>>> like that.
>
>> I would prefer "CREATE {INDEX | SEQUENCE | ... } ACCESS METH
On Fri, Jan 29, 2016 at 12:46 PM, Peter Geoghegan wrote:
> On Fri, Jan 29, 2016 at 9:24 AM, Robert Haas wrote:
>> I feel like this could be data driven. I mean, the cost model is
>> based mainly on the tuple width and the size of the SortTuple array.
>> So, it should be possible to tests of both
Alexander Korotkov writes:
> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera
> wrote:
>> I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something
>> like that.
> I would prefer "CREATE {INDEX | SEQUENCE | ... } ACCESS METHOD name HANDLER
> handler;", but I don't insist.
I think
On Fri, Jan 8, 2016 at 11:58 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> Attached please find improved version of the optimizer patch for LIMIT
> clause.
> Now I try to apply this optimization only for non-trivial columns
> requiring evaluation.
> May be it will be better to take
On Fri, Jan 29, 2016 at 3:17 PM, Alexander Korotkov
wrote:
> Hi, Dilip!
>
> On Tue, Jan 19, 2016 at 6:00 PM, Dilip Kumar wrote:
>>
>>
>> On Tue, Jan 19, 2016 at 5:44 PM, Michael Paquier
>> wrote:
>>>
>>> > Test3:
>>> > pgbench -i -s 100 postgres
>>> > pgbench -c$ -j$ -Mprepared -S postgres
>>> >
Hi, Dilip!
On Tue, Jan 19, 2016 at 6:00 PM, Dilip Kumar wrote:
>
> On Tue, Jan 19, 2016 at 5:44 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> > Test3:
>> > pgbench -i -s 100 postgres
>> > pgbench -c$ -j$ -Mprepared -S postgres
>> >
>> > Client Base
Hi
>
> >
> > You sent only rebased code of previous version. I didn't find additional
> > checks.
>
> Oops. Here is the actual new code.
>
>
New test is working as expected
I did lot of tests - and this code works perfect in single server mode, and
with slave hot-standby mode.
It doesn't work w
Hi, Petr!
On Sat, Jan 23, 2016 at 1:22 AM, Petr Jelinek wrote:
> here is updated version of this patch, calling the messages logical
> (decoding) messages consistently everywhere and removing any connection to
> standby messages. Moving this to it's own module gave me place to write
> some brief
On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera
wrote:
> Petr Jelinek wrote:
> > On 29 January 2016 at 14:48, Tom Lane wrote:
> > > Alvaro Herrera writes:
>
> > > Uh, what? Surely we would provide a bespoke command for each possible
> > > sort of handler. As an example, CREATE INDEX ACCESS ME
On Fri, Jan 29, 2016 at 9:24 AM, Robert Haas wrote:
> I feel like this could be data driven. I mean, the cost model is
> based mainly on the tuple width and the size of the SortTuple array.
> So, it should be possible to tests of both algorithms on 32, 64, 96,
> 128, ... byte tuples with a SortTu
On 29 January 2016 at 16:50, Anastasia Lubennikova
wrote:
> 29.01.2016 19:01, Thom Brown:
>>
>> On 29 January 2016 at 15:47, Aleksander Alekseev
>> wrote:
>>>
>>> I tested this patch on x64 and ARM servers for a few hours today. The
>>> only problem I could find is that INSERT works considerably
On Wed, Jan 27, 2016 at 8:20 AM, Peter Geoghegan wrote:
> Correct me if I'm wrong, but I think that the only outstanding issue
> with all patches posted here so far is the "quicksort with spillover"
> cost model. Hopefully this can be cleared up soon. As I've said, I am
> very receptive to other p
On Tue, Jan 26, 2016 at 5:42 PM, Pavel Stehule wrote:
> I removed from previous patch all OOP related changes. New patch contains
> raise_ functions only. This interface is new generation of previous
> functions: info, notice, warning, error with keyword parameters interface. I
> didn't change
On Fri, Jan 29, 2016 at 3:41 AM, Mithun Cy wrote:
> I just ran some tests on above patch. Mainly to compare
> how "longer sort keys" would behave with new(Qsort) and old Algo(RS) for
> sorting.
> I have 8GB of ram and ssd storage.
>
> Settings and Results.
>
> Work_me
29.01.2016 19:01, Thom Brown:
On 29 January 2016 at 15:47, Aleksander Alekseev
wrote:
I tested this patch on x64 and ARM servers for a few hours today. The
only problem I could find is that INSERT works considerably slower after
applying a patch. Beside that everything looks fine - no crashes,
On 01/29/2016 02:59 AM, Heikki Linnakangas wrote:
Well, I think what people are asking for is precisely a fixed format,
and I do think there is value in that. It's nice to capture the
nuance, but the nuance is going to get flattened out anyway when the
release notes are created. If we all agre
Alvaro Herrera writes:
>> On 29 January 2016 at 14:48, Tom Lane wrote:
> Uh, what? Surely we would provide a bespoke command for each possible
> sort of handler. As an example, CREATE INDEX ACCESS METHOD ought to check
> that the provided function has the right signature, and then it would put
On 29 January 2016 at 15:47, Aleksander Alekseev
wrote:
> I tested this patch on x64 and ARM servers for a few hours today. The
> only problem I could find is that INSERT works considerably slower after
> applying a patch. Beside that everything looks fine - no crashes, tests
> pass, memory doesn'
On 29.01.2016 18:39, Alvaro Herrera wrote:
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 similar word in
I tested this patch on x64 and ARM servers for a few hours today. The
only problem I could find is that INSERT works considerably slower after
applying a patch. Beside that everything looks fine - no crashes, tests
pass, memory doesn't seem to leak, etc.
> Okay, now for some badness. I've restore
Petr Jelinek wrote:
> On 29 January 2016 at 14:48, Tom Lane wrote:
> > Alvaro Herrera writes:
> > Uh, what? Surely we would provide a bespoke command for each possible
> > sort of handler. As an example, CREATE INDEX ACCESS METHOD ought to check
> > that the provided function has the right sig
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 similar word in string:
> contrib_re
On Fri, Jan 29, 2016 at 7:02 AM, Rahila Syed wrote:
> Apart from these, as suggested in [1] , finer grained reporting from index
> vacuuming phase can provide better insight. Currently we report number of
> blocks processed once at the end of vacuuming of each index.
> IIUC, what was suggested in
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> wrote:
> >> > Personally, I don't have any particular issue having both, b
Hello Alvaro,
Thanks for the progress!
I pushed this, along with a few more tweaks, mostly adding comments and
moving functions so that related things are together. I hope I didn't
break anything.
Looks ok.
Here is a rebase of the 3 remaining parts:
- 15-c: per script stats
- 15-d: weigh
On Tue, Dec 29, 2015 at 11:56 AM, Amit Kapila
wrote:
> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
> wrote:
> >
> >
> > In terms of this project overall, NumLWLocks() now knows about only
> > four categories of stuff: fixed lwlocks, backend locks (proc.c),
> > replication slot locks, and locks
Also, a comment is needed to explain why such a bizarre
condition is used/needed for just the INT64_MIN case.
The last patch I sent has this bit:
+ /*
+ * Some machines throw a floating-point exception
+ * for INT64_MIN % -1, the correct answer being
+
On 29.01.2016 17:15, 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 similar word in string:
contrib_regres
The behavior of this function is surprising to me.
select substring_similarity('dog' , 'hotdogpound') ;
substring_similarity
--
0.25
Substring search was desined to search similar word in string:
contrib_regression=# select substring_similarity('dog' ,
On 29 January 2016 at 14:48, Tom Lane wrote:
> Alvaro Herrera writes:
>> I would guess that the DDL boilterplate should come from Alexander
>> Korotkov's patch, right? I think a first easy step may be to combine
>> parts both patches so that we get the "amkind" column from this patch
>> and the
Sure. I attached two patches. But notice that pg_trgm.limit should be used with
this command:
SHOW "pg_trgm.limit";
If you will use this command:
SHOW pg_trgm.limit;
you will get the error:
ERROR: syntax error at or near "limit"
LINE 1: SHOW pg_trgm.limit;
^
This is because
Alvaro Herrera writes:
> I would guess that the DDL boilterplate should come from Alexander
> Korotkov's patch, right? I think a first easy step may be to combine
> parts both patches so that we get the "amkind" column from this patch
> and the DDL support from Alexander's patch (means that his p
28.01.2016 20:03, Thom Brown:
On 28 January 2016 at 16:12, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
28.01.2016 18:12, Thom Brown:
On 28 January 2016 at 14:06, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>> wrote:
31.08.2015 10:41,
On Tue, Jan 5, 2016 at 4:04 PM, Amit Kapila wrote:
> On Mon, Jan 4, 2016 at 8:28 PM, Robert Haas wrote:
> >
> > On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
> wrote:
> > > On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas
> wrote:
> > >> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila >
> > >> wrote:
>
On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
wrote:
> On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera
> wrote:
>> So far as I can tell, there are three patches in flight here:
>>
>> * replication slot IO lwlocks
>> * ability of extensions to request tranches dynamically
>> * PGPROC
>>
>>
On Fri, Jan 8, 2016 at 11:22 PM, Amit Kapila wrote:
> That idea won't work as we need to separately register tranche for
> each process. The other wayout could be to do it in CreateSharedProcArray()
> which will be quite similar to what we do for other tranches and
> it will cover all kind of pro
On Mon, Jan 4, 2016 at 5:58 PM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
> wrote:
> > If we do that way, then user of API needs to maintain the interlock
> > guarantee that the requested number of locks is same as allocations
> > done from that tranche and also if it is n
On 28.01.2016 17:42, Artur Zakirov wrote:
On 27.01.2016 15:28, Artur Zakirov wrote:
On 27.01.2016 14:14, Stas Kelvich wrote:
Hi.
I tried that and confirm strange behaviour. It seems that problem with
small cyrillic letter ‘х’. (simplest obscene language filter? =)
That can be reproduced with
On Fri, Jan 29, 2016 at 6:05 PM, Fabien COELHO wrote:
> (instead of < in my previous suggestion, if some processors return 0 on
> -INT64_MIN). Also, a comment is needed to explain why such a bizarre
> condition is used/needed for just the INT64_MIN case.
The last patch I sent has this bit:
+
On Fri, Jan 29, 2016 at 5:13 PM, Andres Freund wrote:
> On 2016-01-28 16:40:13 +0900, Michael Paquier wrote:
>> OK, so as a first step and after thinking about the whole for a while,
>> I have finished with the patch attached. This patch is aimed at
>> avoiding unnecessary checkpoints on idle syst
Fabien COELHO wrote:
> The answer is essentially yes, the field is needed for the "aggregated" mode
> where this specific behavior is used.
OK, thanks, that looks better to me.
Can you now appreciate why I asked for split patches? If I had to go
over the big patch I probably wouldn't have been
On Fri, Jan 29, 2016 at 5:11 PM, Mithun Cy
wrote
>
>
>
> >I just ran some tests on above patch. Mainly to compare
> >how "longer sort keys" would behave with new(Qsort) and old Algo(RS) for
> sorting.
> >I have 8GB of ram and ssd storage.
>
>
> *Key length 520*
>
>
>
>
> *Number of records* 32
>Okay, I agree that reporting just the current blkno is simple and good
>enough. How about numbers of what we're going to report as the "Vacuuming
>Index and Heap" phase? I guess we can still keep the scanned_index_pages
>and index_scan_count So we have:
>+CREATE VIEW pg_stat_vacuum_progress AS
>+
Petr Jelinek wrote:
> On 18 January 2016 at 09:19, Craig Ringer wrote:
> > Needs rework after the commit of https://commitfest.postgresql.org/8/336/
>
> Here is version that applies to current master. There is some work to
> do (mostly cleanup) and the DDL is missing, but that's because I want
>
On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera
wrote:
> So far as I can tell, there are three patches in flight here:
>
> * replication slot IO lwlocks
> * ability of extensions to request tranches dynamically
> * PGPROC
>
> The first one hasn't been reviewed at all, but the other two have seen
On Tue, Dec 29, 2015 at 4:33 AM, Peter Geoghegan wrote:
>Attached is a revision that significantly overhauls the memory patch,
>with several smaller changes.
I just ran some tests on above patch. Mainly to compare
how "longer sort keys" would behave with new(Qsort) and old Algo(RS) for
sorting.
I
On Fri, Jan 29, 2016 at 1:11 PM, Alvaro Herrera
wrote:
> Artur Zakirov wrote:
>
> > What status of this patch? In commitfest it is "Needs review".
>
> "Needs review" means it needs a reviewer to go over it and, uh, review
> it. Did I send an email to you prodding you to review patches? I sent
>
On 28 January 2016 15:57:15 CET, Robert Haas wrote:
>On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
>>> wrote:
Why can't we do both? That is, have a free-form text with the
>nuances, and
then Reviewed-By list
Robert Haas writes:
> On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane wrote:
>> FWIW, I'm a bit suspicious of the idea that we need to make the commit
>> messages automated-tool-friendly. What tools are there that would need
>> to extract this info, and would we trust them if they didn't understand
>>
Andres Freund writes:
> That's not that hard to change. And neither git nor kernel people use 50
> char limits. I'm *strongly* opposed to making 50 chars the limit for the
> first line.
Ditto. It's hard enough to fit a useful headline in 75 characters.
I personally will ignore any rule that says
Hi,
so, I'm reviewing the output of:
> git diff $(git merge-base upstream/master
> 2ndq/dev/pglogical-output)..2ndq/dev/pglogical-output
> diff --git a/contrib/Makefile b/contrib/Makefile
> index bd251f6..028fd9a 100644
> --- a/contrib/Makefile
> +++ b/contrib/Makefile
> @@ -35,6 +35,8 @@ SUBDIRS
Artur Zakirov wrote:
> What status of this patch? In commitfest it is "Needs review".
"Needs review" means it needs a reviewer to go over it and, uh, review
it. Did I send an email to you prodding you to review patches? I sent
such an email to several people from PostgresPro, but I don't rememb
On 2016-01-29 04:42:08 -0500, Bruce Momjian wrote:
> On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote:
> > I have no prejudice in this area, other than one in favor of any
> > rules being fairly precise. As for nuances, I guess they can be
> > specified in the commit message. The one
On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote:
> I have no prejudice in this area, other than one in favor of any
> rules being fairly precise. As for nuances, I guess they can be
> specified in the commit message. The one thing I do find annoying
> from time to time is the limit o
On Thu, Jan 28, 2016 at 03:16:18PM -0500, Stephen Frost wrote:
> > OK, but keep in mind whatever script committers user should remove tags
> > that are empty after exiting the editor. I can provide the grep regex
> > in git somewhere too:
> >
> > egrep -v
> > "^(Author|Reported-by|Bug|Reviewed
On 21.01.2016 00:25, Alvaro Herrera wrote:
Artur Zakirov wrote:
I don't quite understand why aren't we using a custom GUC variable here.
These already have SHOW and SET support ...
Added GUC variables:
- pg_trgm.limit
- pg_trgm.substring_limit
I added this variables to the documentation.
sho
Hi Michaël,
I think it is overkill, but do as you feel.
Perhaps we could have Robert decide on this one first? That's a bug after
all that had better be backpatched.
Fine with me.
[modulo...] Right, forgot this one, we just need to check if rval is -1
here, and return 0 as result. I am u
On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita
wrote:
> On 2016/01/29 1:26, Ashutosh Bapat wrote:
>
>> Here's an updated version of the previous patches, broken up like before
>>
>
> 2. pg_fdw_join_v3.patch: changes to postgres_fdw - more description below
>>
>
> Here is the summary of changes fr
On Fri, Jan 29, 2016 at 9:51 AM, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 11:26 AM, Ashutosh Bapat
> wrote:
> > 2. pg_fdw_join_v3.patch: changes to postgres_fdw - more description below
>
> This patch no longer quite applies because of conflicts with one of
> your other patches that I applie
On 2016/01/29 1:26, Ashutosh Bapat wrote:
Here's an updated version of the previous patches, broken up like before
2. pg_fdw_join_v3.patch: changes to postgres_fdw - more description below
Here is the summary of changes from the last set of patches
2. Included fix for EvalPlanQual in pos
On 2016-01-28 16:40:13 +0900, Michael Paquier wrote:
> OK, so as a first step and after thinking about the whole for a while,
> I have finished with the patch attached. This patch is aimed at
> avoiding unnecessary checkpoints on idle systems when wal_level >=
> hot_standby by centralizing the chec
71 matches
Mail list logo
