Hi, hackers!
I've adapted crossmatch join from pgSphere to cube for performance tests.
I've placed spatial join code here
https://github.com/Octonica/postgres/blob/spatialjoin/contrib/cube/spatialjoin.c
and node code here
https://github.com/Octonica/postgres/blob/spatialjoin/contrib/cube/joinnode.
Thanks for taking a look.
On 2017/04/28 5:24, Robert Haas wrote:
> On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote
> wrote:
>>> Do we need to update the documentation?
>>
>> Yes, I think we should. How about as in the attached?
>
> Looks reasonable, but I was thinking you might also update the se
On Thu, Apr 27, 2017 at 4:53 PM, Antonin Houska wrote:
> Robert Haas wrote:
>
> > On Wed, Apr 26, 2017 at 6:28 AM, Antonin Houska wrote:
> > > Attached is a diff that contains both patches merged. This is just to
> prove my
> > > assumption, details to be elaborated later. The scripts attached
On Fri, Apr 28, 2017 at 1:32 AM, Robert Haas wrote:
> On Thu, Apr 27, 2017 at 3:41 AM, Ashutosh Bapat
> wrote:
>> The third goal requires that the partition bounds be compared based on
>> the partition keys present in the equi-join. While matching the
>> partitions to be joined, the partition bou
On Mon, Apr 24, 2017 at 2:53 PM, Tom Lane wrote:
> Thomas Munro writes:
>> Every machine sees the LSN moving backwards, but the code path that
>> had the assertion only reached if it decides to interpolate, which is
>> timing dependent: there needs to be a future sample in the lag
>> tracking buf
On Wed, Apr 26, 2017 at 11:17:05AM +1200, Thomas Munro wrote:
> My colleague Prabhat Sahu reported off list that transition tables
> don't work for views. I probably should have thought about that when
> I fixed something similar for partitioned tables, and after some
> experimentation I see that
On Fri, Apr 28, 2017 at 01:55:48PM +0900, Masahiko Sawada wrote:
> On Fri, Apr 28, 2017 at 1:42 PM, Noah Misch wrote:
> > On Fri, Apr 28, 2017 at 06:37:09AM +0900, Fujii Masao wrote:
> >> Pushed. Thanks!
> >
> > Does this close the open item, or is there more to do?
>
> There is only one item rem
On Fri, Apr 28, 2017 at 1:42 PM, Noah Misch wrote:
> On Fri, Apr 28, 2017 at 06:37:09AM +0900, Fujii Masao wrote:
>> Pushed. Thanks!
>
> Does this close the open item, or is there more to do?
There is only one item remaining, and the patch is attached on
here[1]. I guess reviewing that patch is a
On Fri, Apr 21, 2017 at 11:04:14PM +0300, Heikki Linnakangas wrote:
> I'll continue reviewing the rest of the patch on Monday, but [...]
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
upda
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Sun, Apr 23, 2017 at 11:58:23PM +, Stephen Frost wrote:
> > The status is simply that I've been considering Robert's comments regarding
> > the documentation and have had a busy weekend. I'll provide an update
> > tomorrow.
>
> This PostgreSQ
On April 27, 2017 9:34:44 PM PDT, Noah Misch wrote:
>On Fri, Apr 21, 2017 at 10:36:21PM -0700, Andres Freund wrote:
>> On 2017-04-17 21:16:57 -0700, Andres Freund wrote:
>> > I've since the previous update reviewed Petr's patch, which he
>since has
>> > updated over the weekend. I'll do another
On Fri, Apr 28, 2017 at 06:37:09AM +0900, Fujii Masao wrote:
> Pushed. Thanks!
Does this close the open item, or is there more to do?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 21, 2017 at 10:36:21PM -0700, Andres Freund wrote:
> On 2017-04-17 21:16:57 -0700, Andres Freund wrote:
> > I've since the previous update reviewed Petr's patch, which he since has
> > updated over the weekend. I'll do another round tomorrow, and will see
> > how it looks. I think we
On Sun, Apr 23, 2017 at 11:58:23PM +, Stephen Frost wrote:
> Noah, all,
>
> On Sun, Apr 23, 2017 at 19:52 Noah Misch wrote:
>
> > On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> > > On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadbo
On Tue, Apr 25, 2017 at 10:31 AM, Bruce Momjian wrote:
> I have committed the first draft of the Postgres 10 release notes. They
> are current as of two days ago, and I will keep them current. Please
> give me any feedback you have.
>
Related to a following item in release note, oldestxmin is a
Hi
Sometimes I have to solve the result types of some query. It is invisible
in psql. You have to materialize table or you have to create view. Now,
when we can enhance \g command, we can introduce query describing
some like
select a, b from foo
\gdesc
| type | length | collation | .
On Thu, Apr 27, 2017 at 7:53 PM, Marko Tiikkaja wrote:
> On Thu, Apr 27, 2017 at 4:13 PM, Bruce Momjian wrote:
>>
>> On Thu, Apr 27, 2017 at 08:00:28AM +0530, Amit Kapila wrote:
>> > > Oh, so non-correlated subqueries can be run in parallel. Yes, that is
>> > > something we should have in the re
On Thu, Apr 27, 2017 at 11:05 PM, Huong Dangminh
wrote:
>> >>> I would refrain from doing that, having some parameters listed in the
>> >>> tests makes the intention behind those perl routines clear.
>> >
>> > Hmm, you've got a point. But when we changed the default values
>> > related to replicat
On Thu, Apr 27, 2017 at 12:51 AM, Fujii Masao wrote:
> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
> wrote:
>> At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
>> wrote in
>> <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>
>>> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
>>> > T
On Fri, Apr 28, 2017 at 4:00 AM, Peter Eisentraut
wrote:
> On 4/27/17 06:47, Petr Jelinek wrote:
>> One thing I am missing in your patch however is cleanup of entries for
>> relations that finished sync. I wonder if it would be enough to just
>> destroy the hash when we get to empty list.
>
> I ha
On 2017/04/27 12:36, Amit Langote wrote:
> Noticed that a crash occurs if a column is specified twice when creating a
> partition:
>
> create table p (a int) partition by list (a);
>
> -- crashes
> create table p1 partition of parent (
> a not null,
> a default 1
> ) for values in (1);
>
> T
On Thu, Apr 27, 2017 at 4:01 AM, Tom Lane wrote:
> Jeff Janes writes:
> > This gives me compiler warning:
> > launcher.c: In function 'logicalrep_worker_launch':
> > launcher.c:257: warning: 'slot' may be used uninitialized in this
> function
>
> Yeah, me too. Fix pushed.
Somewhat off the mar
On Thu, Apr 27, 2017 at 10:30:54AM +0900, Amit Langote wrote:
> On 2017/04/27 1:52, Robert Haas wrote:
> > On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
> > wrote:
> >> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
> >> In that case, applying only the patch 0001 will do
On Thu, Apr 27, 2017 at 6:32 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao wrote
> in
>> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
>> wrote:
>> > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
>> > wrote in
>> > <3d6a1bd0-08ce-301d-3336-ec9f62
On Thu, Apr 27, 2017 at 5:37 PM, Petr Jelinek
wrote:
> On 26/04/17 18:36, Fujii Masao wrote:
>> On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote:
>>> On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
>>> wrote:
At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
wrote in
>>
Andres Freund writes:
> On 2017-04-27 17:22:25 -0400, Tom Lane wrote:
>> How so? Shouldn't the indexscan go back and mark such tuples dead in
>> the index, such that they'd be visited this way only once? If that's
>> not happening, maybe we should try to fix it.
> One way that never happens is
On 2017-04-27 17:22:25 -0400, Tom Lane wrote:
> > Yep, and I've seen that turn into a serious problem in production.
>
> How so? Shouldn't the indexscan go back and mark such tuples dead in
> the index, such that they'd be visited this way only once? If that's
> not happening, maybe we should tr
Robert Haas writes:
> On Thu, Apr 27, 2017 at 4:08 AM, Dmitriy Sarafannikov
> wrote:
>> I'd like to propose to search min and max value in index with SnapshotAny in
>> get_actual_variable_range function.
> +1 from me, but Tom rejected that approach last time.
I remain concerned about the fact t
Andres Freund writes:
> On 2017-04-27 16:35:29 -0400, Tom Lane wrote:
>> It looks like it might be sufficient to do "#ifdef EPOLL_CLOEXEC"
>> in latch.c, rather than bothering with a full-blown configure check.
> Yea, that sounds worth trying. Wonder if we need to care about kernels
> not suppor
On 2017-04-27 16:35:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-26 17:05:39 -0400, Tom Lane wrote:
> >> I went ahead and changed the call to epoll_create into epoll_create1.
> >> I'm not too concerned about loss of portability there --- it seems
> >> unlikely that many people
On 2017-04-27 16:30:35 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > I've been trying to track down the cause of recent failures at the "make
> > check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
>
> I've been wondering about that too.
Same here. Over the years the
On 04/27/2017 04:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've been trying to track down the cause of recent failures at the "make
>> check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
> I've been wondering about that too.
>
>> Then I tried running (offline mode)
Andres Freund writes:
> On 2017-04-26 17:05:39 -0400, Tom Lane wrote:
>> I went ahead and changed the call to epoll_create into epoll_create1.
>> I'm not too concerned about loss of portability there --- it seems
>> unlikely that many people are still using ten-year-old glibc, and
>> even less lik
Andrew Dunstan writes:
> I've been trying to track down the cause of recent failures at the "make
> check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
I've been wondering about that too.
> Then I tried running (offline mode) the serial schedule instead of the
> parallel sc
On Thu, Apr 27, 2017 at 4:08 AM, Dmitriy Sarafannikov
wrote:
> I'd like to propose to search min and max value in index with SnapshotAny in
> get_actual_variable_range function.
+1 from me, but Tom rejected that approach last time.
> But if we delete many rows from beginning or end of index, it
On Wed, Apr 26, 2017 at 9:30 PM, Amit Langote
wrote:
>> Do we need to update the documentation?
>
> Yes, I think we should. How about as in the attached?
Looks reasonable, but I was thinking you might also update the section
which contrasts inheritance-based partitioning with declarative
partiti
On Thu, Apr 27, 2017 at 3:15 PM, Sven R. Kunze wrote:
> On 27.04.2017 15:07, Robert Haas wrote:
>> On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed
>> wrote:
>>>
>>> +1 for CREATE TABLE..PARTITION OF...DEFAULT syntax.
>>> I think substituting DEFAULT for FOR VALUES is appropriate as
>>> both cases ar
I've been trying to track down the cause of recent failures at the "make
check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
I couldn't see any obvious reason for the failures, and a reboot didn't
cure the problem.
Then I tried running (offline mode) the serial schedule ins
On Thu, Apr 27, 2017 at 3:42 PM, Peter Eisentraut
wrote:
> On 4/27/17 10:03, Robert Haas wrote:
>>> So we could make up new syntax
>>>
>>> ALTER TABLE t1 ALTER COLUMN c1 SET GENERATED ALWAYS AS IDENTITY;
>>>
>>> and let that be set-or-add, but then the argument for staying within the
>>> SQL stand
On Thu, Apr 27, 2017 at 3:41 AM, Ashutosh Bapat
wrote:
> The third goal requires that the partition bounds be compared based on
> the partition keys present in the equi-join. While matching the
> partitions to be joined, the partition bounds corresponding the base
> relation whose partition keys a
On 4/27/17 10:03, Robert Haas wrote:
>> So we could make up new syntax
>>
>> ALTER TABLE t1 ALTER COLUMN c1 SET GENERATED ALWAYS AS IDENTITY;
>>
>> and let that be set-or-add, but then the argument for staying within the
>> SQL standard goes out the window.
>
> What does the SQL standard actually
Hi,
On Apr 27, 2017 18:37, "Robert Haas" wrote:
>
>
> Are you also working on extending this to work with range
> partitioning? Because I think that would be good to do.
>
>
> Currently I am working on review comments and bug fixes for the
default list partitioning patch. After that I can start
On 27/04/17 21:00, Peter Eisentraut wrote:
> On 4/27/17 06:47, Petr Jelinek wrote:
>> One thing I am missing in your patch however is cleanup of entries for
>> relations that finished sync. I wonder if it would be enough to just
>> destroy the hash when we get to empty list.
>
> I had omitted that
On 27.04.2017 15:07, Robert Haas wrote:
On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed wrote:
+1 for CREATE TABLE..PARTITION OF...DEFAULT syntax.
I think substituting DEFAULT for FOR VALUES is appropriate as
both cases are mutually exclusive.
Just to make sound a little rounder:
CREATE TABLE .
On 4/27/17 04:08, Petr Jelinek wrote:
> Note that the workaround for all of this is not all that complex, you do
> same thing (create slot manually) you'd do for physical replication with
> slots.
Maybe we should just document this issue for now.
--
Peter Eisentraut http://www.2ndQu
On 4/27/17 06:47, Petr Jelinek wrote:
> One thing I am missing in your patch however is cleanup of entries for
> relations that finished sync. I wonder if it would be enough to just
> destroy the hash when we get to empty list.
I had omitted that because the amount of memory "leaked" is not much,
Bruce Momjian writes:
> I have committed the first draft of the Postgres 10 release notes. They
> are current as of two days ago, and I will keep them current. Please
> give me any feedback you have.
I noticed a few niggles with the links in "my" entires, patch attached.
Cheers,
ilmari
--
On Thu, Apr 27, 2017 at 5:06 PM, Robert Haas wrote:
> On Wed, Apr 26, 2017 at 11:39 AM, Alexander Korotkov
> wrote:
> > But I'd like to make incremental sort not slower than quicksort in case
> of
> > presorted data. New idea about it comes to my mind. Since cause of
> > incremental sort slown
On Thu, Apr 27, 2017 at 4:13 PM, Bruce Momjian wrote:
> On Thu, Apr 27, 2017 at 08:00:28AM +0530, Amit Kapila wrote:
> > > Oh, so non-correlated subqueries can be run in parallel. Yes, that is
> > > something we should have in the release notes. How is this?
> > >
> > > Author: Robert H
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> >> So to summarize what the patches do (some of these were posted earlier)
> >>
> >> 0002: pg_dump: Do not emit WITH OPTIONS keywords with partition's columns
> >
> > I'm trying to understand why this is also different. At least on an
On Thu, Apr 27, 2017 at 08:14:34AM +0530, Amit Kapila wrote:
>
>
>
> Improve efficiency of hash index growth (Amit Kapila, Mithun Cy)
>
>
>
> The first two commits b0f18cb77, 30df93f69 are done as preliminary
> work to "Add write-ahead logging support to hash
On Thu, Apr 27, 2017 at 08:00:28AM +0530, Amit Kapila wrote:
> > Oh, so non-correlated subqueries can be run in parallel. Yes, that is
> > something we should have in the release notes. How is this?
> >
> > Author: Robert Haas
> > 2017-02-14 [5e6d8d2bb] Allow parallel workers to
On Wed, Apr 26, 2017 at 11:39 AM, Alexander Korotkov
wrote:
> But I'd like to make incremental sort not slower than quicksort in case of
> presorted data. New idea about it comes to my mind. Since cause of
> incremental sort slowness in this case is too frequent reset of tuplesort,
> then what i
> >>> I would refrain from doing that, having some parameters listed in the
> >>> tests makes the intention behind those perl routines clear.
> >
> > Hmm, you've got a point. But when we changed the default values
> > related to replication we dropped some explicitly settings from the
> > regressio
On Wed, Apr 26, 2017 at 10:03 PM, Peter Eisentraut
wrote:
> On 4/23/17 16:58, Robert Haas wrote:
>> I agree that ADD is a little odd here, but it doesn't seem terrible.
>> But why do we need it? Instead of:
>>
>> ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
>> SET GENERATED { ALWAYS | BY DEF
On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed wrote:
>>I suspect it could be done as of now, but I'm a little worried that it
>>might create grammar conflicts in the future as we extend the syntax
>>further. If we use CREATE TABLE ... PARTITION OF .. DEFAULT, then the
>>word DEFAULT appears in the
Fabien COELHO wrote:
>Fix psql \p to always print what would be executed by \g or \w (Daniel
>Vérité)
>
>Previously \p didn't properly print the reverted-to command after a
>buffer contents reset. CLARIFY?
>
> The fix is linked to the change introduced by Tom when
> refa
>I suspect it could be done as of now, but I'm a little worried that it
>might create grammar conflicts in the future as we extend the syntax
>further. If we use CREATE TABLE ... PARTITION OF .. DEFAULT, then the
>word DEFAULT appears in the same position where we'd normally have FOR
>VALUES, and
On 25/04/17 19:54, Peter Eisentraut wrote:
> I feel it's getting a bit late for reworkings of this extent, also
> considering the marginal nature of the problem we are trying to fix. My
> patch from April 18 is very localized and gets the job done.
>
> I think this is still a good direction to in
At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao wrote
in
> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
> wrote:
> > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
> > wrote in
> > <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>
> >> On 4/6/17 08:24, Kyotaro HORIGUCHI wrot
Hello Bruce,
I have committed the first draft of the Postgres 10 release notes. They
are current as of two days ago, and I will keep them current. Please
give me any feedback you have.
About:
"""
Fix psql \p to always print what would be executed by \g or \w (Daniel
Vérité)
Previous
On 26/04/17 18:36, Fujii Masao wrote:
> On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote:
>> On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
>> wrote:
>>> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
>>> wrote in
>>>
On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek
wrote:
Hi All,
I have a working prototype now, but there is one aspect I haven't been
able to find the best solution for.
The CLI interface so far has the following new added option:
-C, --compressprog=PRG use supplied external program for compression
An example usage would be:
pg_basebackup
On 27/04/17 04:50, Tom Lane wrote:
> Peter Eisentraut writes:
If that's a predictable deadlock, I think a minimum expectation is that
the system should notice it and throw an error, not just hang.
>
>> We had some discussions early on about detecting connections to the same
>> server, b
Hi Stephen,
On 2017/04/26 23:31, Stephen Frost wrote:
>>> I looked through
>>> pg_get_partkeydef() and it didn't seem to be particularly expensive to
>>> run, though evidently it doesn't handle being passed an OID that it
>>> doesn't expect very cleanly:
>>>
>>> =# select pg_get_partkeydef(oid) fr
Hi hackers,I'd like to propose to search min and max value in index with SnapshotAny in get_actual_variable_range function.Current implementation scans index with SnapshotDirty which accepts uncommitted rows and rejects dead rows.In a code there is a comment about this: /* * In p
On Thu, Apr 27, 2017 at 4:33 PM, Masahiko Sawada wrote:
> On Thu, Apr 27, 2017 at 1:58 PM, Huong Dangminh
> wrote:
>>> On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada
>>> wrote:
>>> > Thank you for updating the patch. Also maybe we can update line in
>>> > PostgresNode.pm where hot_standby is
On Wed, Apr 26, 2017 at 9:30 PM, Robert Haas wrote:
> On Mon, Apr 24, 2017 at 7:06 AM, Ashutosh Bapat
> wrote:
>> This assumes that datums in partition bounds have one to one mapping
>> with the partitions, which isn't true for list partitions. For list
>> partitions we have multiple datums corre
On Thu, Apr 27, 2017 at 1:58 PM, Huong Dangminh
wrote:
>> On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada
>> wrote:
>> > Thank you for updating the patch. Also maybe we can update line in
>> > PostgresNode.pm where hot_standby is set to on explicitly.
>>
>> I would refrain from doing that, havi
On Fri, Apr 21, 2017 at 6:24 AM, Claudio Freire wrote:
> On Wed, Apr 12, 2017 at 4:35 PM, Robert Haas wrote:
>> On Tue, Apr 11, 2017 at 4:38 PM, Claudio Freire
>> wrote:
>>> In essence, the patch as it is proposed, doesn't *need* a binary
>>> search, because the segment list can only grow up to
On 04/26/2017 07:57 PM, Tom Lane wrote:
Robert Haas writes:
On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote:
* If algorithm is not given explicitly, PQencryptPasswordConn() queries
"SHOW password_encryption", and uses that. That is documented, and it is
also documented that it will
71 matches
Mail list logo