2018-05-26 22:56 GMT+02:00 Vik Fearing :
> SQL:2011 introduced the concept of a "period". It takes two existing
> columns and basically does the same thing as our range types except there
> is no new storage. I believe if Jeff Davis had given us range types a few
> years later than he did, it wou
On 05/25/2018 03:04 PM, Bruce Momjian wrote:
On Sun, May 6, 2018 at 11:53:34AM -0400, Tom Lane wrote:
What sort of changes do we get if we remove those two flags as you prefer?
It'd help to see some examples.
Since we just went to a new perltidy version, and made some other
policy changes fo
>
> I think we're going to have to continue showing the tree plan. I think
> the linear version is far too hard to understand for anything
> nontrivial.
>
Hey Andres, what you're pitching here is very similar to the way DB2 works.
It actually has two different explain tools that dumps the two diff
On 05/18/2018 02:02 PM, Andrew Dunstan wrote:
These two small patches allow us to run "perl -cw" cleanly on all our
perl code.
One patch silences a warning from convutils.pl about the unportability
of the literal 0x1. We've run for many years without this
giving us a problem, so
On May 26, 2018, at 1:45 PM, Andres Freund wrote:
> Does anybody see a way to not have to remove the .init file?
How about only keeping the critical info for being able to find relations in
the .init files, and then fully populate the cache by doing a normal lookup?
Since there’s multiple entri
On May 27, 2018 9:39:49 AM PDT, "Nasby, Jim" wrote:
>On May 26, 2018, at 1:45 PM, Andres Freund wrote:
>> Does anybody see a way to not have to remove the .init file?
>
>How about only keeping the critical info for being able to find
>relations in the .init files, and then fully populate the ca
Andres Freund writes:
> On May 27, 2018 9:39:49 AM PDT, "Nasby, Jim" wrote:
>> How about only keeping the critical info for being able to find
>> relations in the .init files, and then fully populate the cache by
>> doing a normal lookup?
> Then the cache wouldn't have any benefits, no? It's bee
Hi,
While preparing for an upcoming presentation, I was playing around
with SP-GiST indexes on tstz ranges and was having an issue where
some would fail to build to completion in a reasonable time, especially
compared to corresponding GiST builds.
Version:
PostgreSQL 10.4 on x86_64-apple
Hi,
On 2018-05-27 13:22:21 -0400, Tom Lane wrote:
> But I don't think there's any need for special magic here: we just
> have to accept the fact that there's a need to flush that cache
> sometimes. In normal use it shouldn't happen often enough to be a
> performance problem.
Yea, it's not that p
> On 26 May 2018 at 16:47, Andrew Dunstan
> wrote:
> On 05/26/2018 03:09 AM, Piotr Stefaniak wrote:
>> On 2018-05-26 02:02, Peter Eisentraut wrote:
>>>
>>> It can be fixed this way:
>>>
>>> --- a/src/backend/utils/adt/jsonb_util.c
>>> +++ b/src/backend/utils/adt/jsonb_util.c
>>> @@ -901,7 +901,7
On Sun, May 27, 2018 at 12:45 PM, Jonathan S. Katz wrote:
> Next, see bad.sql. 1.2MM sparsely clustered rows inserted, GiST indexes
> builds in about 30s on my machine. SP-GiST does not build at all, or at
> least I have been composing this email for about 10 minutes since I kicked
> off my late
On Sun, May 27, 2018 at 2:09 PM, Peter Geoghegan wrote:
> On Sun, May 27, 2018 at 12:45 PM, Jonathan S. Katz
> wrote:
>> Next, see bad.sql. 1.2MM sparsely clustered rows inserted, GiST indexes
>> builds in about 30s on my machine. SP-GiST does not build at all, or at
>> least I have been compo
Peter Geoghegan writes:
> Looks like I spoke too soon. The SP-GiST index build finished a moment
> ago. The index build took a horrifically long time for a 122 MB index,
> though.
Instrumenting the test case suggests that getQuadrant pretty much always
returns 1, resulting in a worst-case unbalan
On Sun, May 27, 2018 at 5:10 PM, Tom Lane wrote:
> Instrumenting the test case suggests that getQuadrant pretty much always
> returns 1, resulting in a worst-case unbalanced SPGiST tree. I think this
> is related to the fact that the test case inserts the values in increasing
> order, so that new
On Sun, May 27, 2018 at 5:24 PM, Peter Geoghegan wrote:
> On Sun, May 27, 2018 at 5:10 PM, Tom Lane wrote:
>> Instrumenting the test case suggests that getQuadrant pretty much always
>> returns 1, resulting in a worst-case unbalanced SPGiST tree. I think this
>> is related to the fact that the t
On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote:
> On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
>> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>>
>>> OK, I can live with that as well. So we'll go in the direction of two
>>> parameters then:
>
I suppose I can make summary after reading all this:
1. Any change in the development process will be possible if it will be
convenient for each key developers personally only. (development process
include build system)
2. Currently, almost all key developers use Unix like systems, they have
strong
>
> Can't see getting rid of those entirely. None of the github style
> platforms copes with reasonable complex discussions.
I disagree. A good example of complex discussions on github is Rust
language tracker for RFCs:
https://github.com/rust-lang/rfcs/issues
and one concrete example: https://gi
Thank you for the comment.
At Fri, 25 May 2018 10:08:08 -0400, Tom Lane wrote in
<3389.1527257...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > It is set for other kinds of message, (parse, bind, execute). I
> > think fastpath, close, flush and sync don't need that. If it is
> > reasonable to
On Thu, Mar 08, 2018 at 02:19:55PM -0500, Peter Eisentraut wrote:
> Moved to next CF along with those other two patches.
Attached is a refreshed patch for this thread, which failed to apply
after recent changes. This is tied with patches for other SSL
implementations, so let's see about it later
Thanks! I've been waiting for this.
At Thu, 24 May 2018 20:35:39 -0700, Andres Freund wrote in
<20180525033538.6ypfwcqcxce6z...@alap3.anarazel.de>
> The current executor structure limits us in a number of ways that are
> becoming problematic. I'll outline in this email how I think we should
> r
Exciting stuff! Really looking forward to having a play with this.
James Sewell,
*Chief Architect*
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F *
(+61) 2 8099 9099 <(+61)%202%208099%209000>
On 25 May
> On May 27, 2018, at 8:24 PM, Peter Geoghegan wrote:
>
> On Sun, May 27, 2018 at 5:10 PM, Tom Lane wrote:
>> Instrumenting the test case suggests that getQuadrant pretty much always
>> returns 1, resulting in a worst-case unbalanced SPGiST tree. I think this
>> is related to the fact that the
23 matches
Mail list logo
