Re: Finding database for pg_upgrade missing library

On Fri, Jul 13, 2018 at 12:28:15PM -0400, Bruce Momjian wrote: > I received a private pg_upgrade feature request to report the database > name for missing loadable libraries. Currently we report "could not > load library" and the library file name, e.g. $libdir/pgpool-regclass. > > The request

Re: Fix some error handling for read() and errno

On 2018-Jul-14, Michael Paquier wrote: > On Fri, Jul 13, 2018 at 11:31:31AM -0400, Alvaro Herrera wrote: > >> Mr. Robot has been complaining about this patch set, so attached is a > >> rebased version. Thinking about it, I would tend to just merge 0001 and > >> give up on 0002 as that may not

Re: Vacuum: allow usage of more than 1GB of work mem

On 07/13/2018 09:44 AM, Heikki Linnakangas wrote: On 13/07/18 01:39, Andrew Dunstan wrote: On 07/12/2018 06:34 PM, Alvaro Herrera wrote: On 2018-Jul-12, Andrew Dunstan wrote: I fully understand. I think this needs to go back to "Waiting on Author". Why?  Heikki's patch applies fine and

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

Andrew Dunstan writes: > On 07/09/2018 11:34 AM, Tom Lane wrote: >> I think the most practical way to deal with this probably is to change >> the parser so that the lookup works by finding a default btree or hash >> opclass rather than by looking for "=" by name. We've made similar >> changes in

Re: [WIP PATCH] Index scan offset optimisation using visibility map

On 21/05/18 18:43, Michail Nikolaev wrote: Hello everyone. This letter related to “Extended support for index-only-scan” from my previous message in the thread. WIP version of the patch is ready for a while now and I think it is time to resume the work on the feature. BTW, I found a small

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

On 07/13/2018 05:23 PM, Tom Lane wrote: "David G. Johnston" writes: I think serious consideration needs to be given to ways to allow the user of pg_dump/pg_restore to choose the prior, less secure, mode of operation​. IMO the risk surface presented to support back-patching the behavioral

Re: [PATCH] LLVM tuple deforming improvements

On Friday, July 13, 2018 11:08:45 PM CEST Andres Freund wrote: > Hi, > > Thanks for looking at this! > > On 2018-07-13 10:20:42 +0200, Pierre Ducroquet wrote: > > 2) improve the LLVM IR code > > > > The code generator in llvmjit-deform.c currently rely on the LLVM > > optimizer to do the right

Re: automatic restore point

On Fri, Jul 13, 2018 at 08:16:00AM +, Yotsunaga, Naoki wrote: > Do you feel it is too complicated? In short, yes. -- Michael signature.asc Description: PGP signature

Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Adds the options RESPECT/IGNORE NULLS (null treatment clause) and FROM FIRST/LAST to the non-aggregate window functions. A previous patch (https://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com) partially implemented this feature. However, that

Re: Temporary WAL segments files not cleaned up after an instance crash

On Thu, 12 Jul 2018 16:44:45 +0900 Michael Paquier wrote: > On Thu, Jul 12, 2018 at 03:35:53PM +0900, Yugo Nagata wrote: > > I think it makes sense to remove unnecessary temporary WAL files although > > I'm not sure how high the risk of ENOSPC is. > > It depends on how close to the partition

function lca('{}'::ltree[]) caused DB Instance crash

HI,Oleg && pgsql-hackers Plese help me to check this is a bug of ltree? thxs! lhl@localhost:~$ cat /etc/issue Ubuntu 14.04.5 LTS \n \l lhl@localhost:~$ uname -av Linux localhost 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20 09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Re: Problem on pg_dump RANGE partition with expressions

On Thu, 12 Jul 2018 17:44:48 +0900 Amit Langote wrote: > > 1) Allow to appear more than once in range partition key > > > > I don't understand why there is this restriction. If we have no clear > > reason, > > can we rip out this restrition? > > I can't recall exactly, but back when I wrote

Re: patch to allow disable of WAL recycling

Thanks to everyone who has taken the time to look at this patch and provide all of the feedback. I'm going to wait another day to see if there are any more comments. If not, then first thing next week, I will send out a revised patch with improvements to the man page change as requested. If

Re: How to make partitioning scale better for larger numbers of partitions

On Fri, Jul 13, 2018 at 9:23 AM, Kato, Sho wrote: >>I wondered if you compared to PG10 or to inheritence-partitioning (parent >>with relkind='r' and either trigger or rule or >INSERT/UPDATE directly into >>child) ? > > Thank you for your reply. > > I compared to PG11beta2 with non-partitioned

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

On Fri, Jul 13, 2018 at 1:15 PM, Amit Langote wrote: >> >> I don't think this is true. When equality conditions and IS NULL clauses >> cover >> all partition keys of a hash partitioned table and do not have contradictory >> clauses, we should be able to find the partition which will remain

Re: Fix some error handling for read() and errno

On Mon, Jun 25, 2018 at 04:18:18PM +0900, Michael Paquier wrote: > As this one is done, I have been looking at that this thread again. > Peter Eisentraut has pushed as e5d11b9 something which does not need to > worry about pluralization of error messages. So I have moved to this > message style

Re: file cloning in pg_upgrade and CREATE DATABASE

On Fri, Jul 13, 2018 at 10:22:21AM +0200, Peter Eisentraut wrote: > On 13.07.18 07:09, Thomas Munro wrote: >> TIL that Solaris 11.4 (closed) ZFS supports reflink() too. Sadly, >> it's not in OpenZFS though I see numerous requests and discussions... > > I look forward to your FreeBSD patch then.

Re: Vacuum: allow usage of more than 1GB of work mem

On 13/07/18 01:39, Andrew Dunstan wrote: On 07/12/2018 06:34 PM, Alvaro Herrera wrote: On 2018-Jul-12, Andrew Dunstan wrote: I fully understand. I think this needs to go back to "Waiting on Author". Why? Heikki's patch applies fine and passes the regression tests. Well, I understood

Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation

On Thu, Jul 12, 2018 at 2:29 PM, Amit Langote wrote: > Thanks Ashutosh. > > On 2018/07/10 22:50, Ashutosh Bapat wrote: >> I didn't see any hackers thread linked to this CF entry. Hence sending this >> mail through CF app. > > Hmm, yes. I hadn't posted the patch to -hackers. > >> The patch looks

Re: function lca('{}'::ltree[]) caused DB Instance crash

On Friday, July 13, 2018 12:09:20 PM CEST 李海龙 wrote: > HI,Oleg && pgsql-hackers > > Plese help me to check this is a bug of ltree? > Hi There is indeed a bug. The _lca function in _ltree_op.c tries to allocate 0 bytes of memory, doesn't initialize it and dereference it in lca_inner. The

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 24 June 2018 at 20:45, Tomas Vondra wrote: > Attached is a rebased version of this patch series, mostly just fixing > the breakage caused by reworked format of initial catalog data. > > Aside from that, the MCV building now adopts the logic introduced by > commit b5db1d93d2 for single-column

Re: [HACKERS] WIP: Data at rest encryption

Hi. I am interested in a patch of "WIP: Data at rest encryption". This patch("data-at-rest-encryption-wip-2018.06.27.patch") is applied to PostgreSQL 11-beta 2 and it is running. In the explanation of this patch, since "data stored during logical decoding" is written, we tried logical

Re: How to make partitioning scale better for larger numbers of partitions

On Fri, Jul 13, 2018 at 05:49:20AM +, Tsunakawa, Takayuki wrote: > David has submitted multiple patches for PG 12, one of which speeds up > pruning of UPDATE/DELETE (I couldn't find it in the current CF, though.) > What challenges are there for future versions, and which of them are being

Re: How to make partitioning scale better for larger numbers of partitions

On 13 July 2018 at 14:58, Kato, Sho wrote: > Of course I'm sure table partitioning work well with up to a hundred > partitions as written on the postgresql document. > > But, my customer will use partitioned table with 1.1k leaf partitions. > > So, we need to improve performance. > > Any ideas?

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/13 14:49, Tsunakawa, Takayuki wrote: > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] >> For SELECT/UPDATE/DELETE, overhead of partitioning in the planning phase >> is pretty significant and gets worse as the number of partitions grows. >> I >> had intended to fix that in PG

RE: How to make partitioning scale better for larger numbers of partitions

From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > The immediate one I think is to refactor the planner such that the new > pruning code, that we were able to utilize for SELECT in PG 11, can also > be used for UPDATE/DELETE. Refactoring needed to replace the pruning > algorithm was

Re: How to make partitioning scale better for larger numbers of partitions

On 13 July 2018 at 18:53, Tsunakawa, Takayuki wrote: > By the way, what do you think is the "ideal and should-be-feasible" goal and > the "realistic" goal we can reach in the near future (e.g. PG 12)? Say, Depends. Patched don't move that fast without review and nothing gets committed without

RE: Global shared meta cache

Hi, Konstantin >Hi, >I really think that we need to move to global caches (and especially catalog >caches) in >Postgres. >Modern NUMA servers may have hundreds of cores and to be able to utilize all >of them, >we may need to start large number (hundreds) of backends. >Memory overhead of local

RE: How to make partitioning scale better for larger numbers of partitions

From: David Rowley [mailto:david.row...@2ndquadrant.com] > > David has submitted multiple patches for PG 12, one of which speeds up > pruning of UPDATE/DELETE (I couldn't find it in the current CF, though.) > What challenges are there for future versions, and which of them are being > addressed by

Re: How can we submit code patches that implement our (pending) patents?

On Sat, Jul 7, 2018 at 9:01 PM Andres Freund wrote: > Hi, > > On 2018-07-07 20:51:56 +0200, David Fetter wrote: > > As to "dual license," that's another legal thicket in which we've been > > wise not to involve ourselves. "Dual licensing" is generally used to > > assert proprietary rights

Re: Cannot dump foreign key constraints on partitioned table

Thanks for the prompt fix, patch [1] works for me. 1] https://postgr.es/m/20180712184537.5vjwgxlbuiomomqd@alvherre.pgsql Regards, Amul

Re: How to make partitioning scale better for larger numbers of partitions

On 13 July 2018 at 17:49, Tsunakawa, Takayuki wrote: > David has submitted multiple patches for PG 12, one of which speeds up > pruning of UPDATE/DELETE (I couldn't find it in the current CF, though.) > What challenges are there for future versions, and which of them are being > addressed by

Re: [PATCH] Include application_name in "connection authorized" log message

On 02.07.18 15:12, Don Seiler wrote: > On Mon, Jul 2, 2018 at 2:13 AM, Peter Eisentraut > > wrote: > > On 21.06.18 16:21, Don Seiler wrote: > > -                                               (errmsg("connection > > authorized: user=%s

Re: Constraint documentation

On 07.07.18 10:23, Fabien COELHO wrote: > I'm not sure what is the suggestion wrt to the documentation text. Is the > issue only with the first introductory sentence? Would removing it be > enough? Yes. But it would be even better to fix pg_dump. -- Peter Eisentraut

Re: Constraint documentation

Hello Peter, I'm not sure what is the suggestion wrt to the documentation text. Is the issue only with the first introductory sentence? Would removing it be enough? Yes. But it would be even better to fix pg_dump. Sure. The purpose of Lætitia patch is simply to document the consequences

Re: pgbench's expression parsing & negative numbers

Hello Andres, I'll come up with a patch for that sometime soon. ISTM that you have not sent any patch on the subject, otherwise I would have reviewed it. Maybe I could do one some time later, unless you think that I should not. Here is a patch which detects pgbench overflows on int &

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

Thanks for the review. On 2018/07/12 22:01, Ashutosh Bapat wrote: > On Thu, Jul 12, 2018 at 11:10 AM, Amit Langote > wrote: >>> >>> I think your fix is correct. I slightly modified it along with updating >>> nearby comments and added regression tests. >> >> I updated regression tests to reduce

Re: Preferring index-only-scan when the cost is equal

On Thu, 12 Jul 2018 12:59:15 +0200 Tomas Vondra wrote: > > > On 07/12/2018 03:44 AM, Yugo Nagata wrote: > > On Wed, 11 Jul 2018 14:37:46 +0200 > > Tomas Vondra wrote: > > > >> > >> On 07/11/2018 01:28 PM, Ashutosh Bapat wrote: > > > >>> I don't think we should change add_path() for this. We

Re: [HACKERS] Restricting maximum keep segments by repslots

Hello. At Wed, 11 Jul 2018 15:09:23 +0900, Masahiko Sawada wrote in > On Mon, Jul 9, 2018 at 2:47 PM, Kyotaro HORIGUCHI > wrote: .. > Here is review comments of v4 patches. > > + if (minKeepLSN) > + { > + XLogRecPtr slotPtr = XLogGetReplicationSlotMinimumLSN(); > +

Re: ALTER TABLE on system catalogs

On 28.06.18 10:14, Peter Eisentraut wrote: > On 6/28/18 01:10, Michael Paquier wrote: >> On Wed, Jun 27, 2018 at 01:37:33PM -0700, Andres Freund wrote: >>> On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote: I propose that we instead silently ignore attempts to add TOAST tables to

Re: How to make partitioning scale better for larger numbers of partitions

On 2018/07/13 16:29, Kato, Sho wrote: > I also benchmark PG10. > Actually, SELECT latency on PG11beta2 + patch1 is faster than PG10. > > SELECT latency with 800 leaf partition > -- > PG10　5.62 ms > PG11 3.869 ms > > But, even PG11, SELECT statement takes

RE: automatic restore point

>-Original Message- >From: Michael Paquier [mailto:mich...@paquier.xyz] >Sent: Wednesday, July 11, 2018 3:34 PM >Well, if you put in place correct measures from the start you would not have >problems. >It seems to me that there is no point in implementing something which is a

[PATCH] LLVM tuple deforming improvements

Hi As reported in the «effect of JIT tuple deform?» thread, there are for some cases slowdowns when using JIT tuple deforming. I've played with the generated code and with the LLVM optimizer trying to fix that issue, here are the results of my experiments, with the corresponding patches. All

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Hi David. On 2018/06/22 15:28, David Rowley wrote: > Hi, > > As part of my efforts to make partitioning scale better for larger > numbers of partitions, I've been looking at primarily INSERT VALUES > performance. Here the overheads are almost completely in the > executor. Planning of this type

RE: How to make partitioning scale better for larger numbers of partitions

Tsunakawa-san >Kato-san, could you try pgbench -M prepared? I did pgbench -M prepared and perf record. UPDATE latency in prepared mode is 95% shorter than in simple mode. SELECT latency in prepared mode is 54% shorter than in simple mode. INSERT latency in prepared mode is 8% shorter than in

Re: function lca('{}'::ltree[]) caused DB Instance crash

Pierre Ducroquet writes: > On Friday, July 13, 2018 12:09:20 PM CEST 李海龙 wrote: >> contrib_regression=# select lca('{}'::ltree[]); >> server closed the connection unexpectedly > There is indeed a bug. The _lca function in _ltree_op.c tries to allocate 0 > bytes of memory, doesn't initialize it

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

On Thu, Jul 12, 2018 at 4:32 PM, Etsuro Fujita wrote: > > In this example, the value of the whole-row reference to the child table > ptp1 for that record is ('foo',1), and that of the index expression for that > record is (1,'foo'). Those have different column orders, but the latter > could be

Re: GiST VACUUM

On 13/07/18 16:41, Andrey Borodin wrote: 12 июля 2018 г., в 21:07, Andrey Borodin > написал(а): 12 июля 2018 г., в 20:40, Heikki Linnakangas > написал(а): Actually, now that I think about it more, I'm not happy with leaving orphaned pages like

Re: Problem with tupdesc in jsonb_to_recordset

Andrew Gierth writes: > What's happening in the original case is this: the SRF call protocol > says that it's the executor's responsibility to free rsi.setDesc if it's > not refcounted, under the assumption that in such a case it's in > per-query memory (and not in either a shorter-lived or

Re: [HACKERS] Client Connection redirection support for PostgreSQL

On 05/03/18 22:18, Satyanarayana Narlapuram wrote: Please see the attached patch with the comments. Changes in the patch: A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries. BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1

Re: Generating partitioning tuple conversion maps faster

On 09/07/18 22:58, David Rowley wrote: On 9 July 2018 at 23:28, Alexander Kuzmenkov wrote: On 07/09/2018 10:13 AM, David Rowley wrote: I've attached v5. v5 looks good to me, I've changed the status to ready. Many thanks for reviewing this. Pushed, thanks! - Heikki

Re: requested timeline ... does not contain minimum recovery point ...

> On Jul 12, 2018, at 19:54, Andres Freund wrote: > Do you see a "checkpoint complete: wrote ..." message > before the rewind started? Checking, but I suspect that's exactly the problem. This raises a question: Would it make sense for pg_rewind to either force a checkpoint or have a

Finding database for pg_upgrade missing library

I received a private pg_upgrade feature request to report the database name for missing loadable libraries. Currently we report "could not load library" and the library file name, e.g. $libdir/pgpool-regclass. The request is that we report the _database_ name that contained the loadable library

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 07/13/2018 01:19 PM, Dean Rasheed wrote: > On 24 June 2018 at 20:45, Tomas Vondra wrote: >> Attached is a rebased version of this patch series, mostly just fixing >> the breakage caused by reworked format of initial catalog data. >> >> Aside from that, the MCV building now adopts the logic

Re: Cannot dump foreign key constraints on partitioned table

On 2018-Jul-13, amul sul wrote: > Thanks for the prompt fix, patch [1] works for me. > > 1] https://postgr.es/m/20180712184537.5vjwgxlbuiomomqd@alvherre.pgsql Thanks for checking, pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

On 18/04/18 09:55, Thomas Munro wrote: Here's a draft patch that does that. One contentious question is: should you have to opt *in* to auto-exit-on-postmaster death? Andres opined that you should. I actually think it's not so bad if you don't have to do that, and instead have to opt out. I

Re: GiST VACUUM

> 13 июля 2018 г., в 18:10, Heikki Linnakangas написал(а): > But the situation in gistdoinsert(), where you encounter a deleted leaf page, could happen during normal operation, if vacuum runs concurrently with an insert. Insertion locks only one page at a time, as it descends

Re: pgsql: Fix parallel index and index-only scans to fall back to serial.

Hi! I just bumped into this comment, from commit 09529a70bb5, and I can't make sense of it: + /* +* We reach here if the index only scan is not parallel, or if we're +* executing a index only scan that was intended to be parallel +

Logical decoding from promoted standby with same replication slot

Hello - We are working on several DR scenarios with logical decoding. Although we are using pglogical the question we have I think is generally applicable to logical replication. Say we have need to drop a logical replication slot for some emergency reason on the master, but we don't want to

Re: [PATCH] Include application_name in "connection authorized" log message

On Fri, Jul 13, 2018 at 10:13 AM, Don Seiler wrote: > On Fri, Jul 13, 2018 at 9:37 AM, Stephen Frost wrote: > >> >> Don, do you want to update the patch accordingly? If not, I'm happy to >> handle it when I go to commit it, which I'm thinking of doing sometime >> this weekend as it seems to be

Re: [HACKERS] Client Connection redirection support for PostgreSQL

> > > > One thing where I can see a feature like this being quite helpful is > planned failovers, reducing the time to reconnect (for existing > connections) and rediscover (for new connections, which need to > write). But that'd require that the redirect needs to be able to be sent > in an

Re: pgsql: Fix parallel index and index-only scans to fall back to serial.

On Fri, Jul 13, 2018 at 12:22 PM, Heikki Linnakangas wrote: > Hi! > > I just bumped into this comment, from commit 09529a70bb5, and I can't make > sense of it: > > + /* >> +* We reach here if the index only scan is not parallel, >> or if we're >> +*

Re: Finding database for pg_upgrade missing library

> On 13 Jul 2018, at 18:28, Bruce Momjian wrote: > > I received a private pg_upgrade feature request to report the database > name for missing loadable libraries. Currently we report "could not > load library" and the library file name, e.g. $libdir/pgpool-regclass. > > The request is that we

Re: Fix some error handling for read() and errno

On Fri, Jul 13, 2018 at 11:31:31AM -0400, Alvaro Herrera wrote: >> Mr. Robot has been complaining about this patch set, so attached is a >> rebased version. Thinking about it, I would tend to just merge 0001 and >> give up on 0002 as that may not justify future backpatch pain. Thoughts >> are

Re: [HACKERS] Client Connection redirection support for PostgreSQL

On 2018-07-13 23:00:04 +0300, Heikki Linnakangas wrote: > On 05/03/18 22:18, Satyanarayana Narlapuram wrote: > > Please see the attached patch with the comments. > > > > Changes in the patch: > > A client-side PGREDIRECTLIMIT parameter has been introduced to control > > the maximum number of

Re: partition pruning doesn't work with IS NULL clause in multikey range partition case

On 2018-Jul-13, Ashutosh Bapat wrote: > On Fri, Jul 13, 2018 at 1:15 PM, Amit Langote > wrote: > >> > >> I don't think this is true. When equality conditions and IS NULL clauses > >> cover > >> all partition keys of a hash partitioned table and do not have > >> contradictory > >> clauses, we

Fwd: GSOC 2018 Project - A New Sorting Routine

-- Forwarded message -- From: Kefan Yang Date: 2018-07-13 15:02 GMT-07:00 Subject: Re: GSOC 2018 Project - A New Sorting Routine To: Tomas Vondra Hey Tomas, Thanks for your reply! First I’d like to make some clarification about my test result. > First of all, testing

Re: Generating partitioning tuple conversion maps faster

On 14 July 2018 at 04:57, Heikki Linnakangas wrote: > Pushed, thanks! Thanks for pushing, and thanks again for reviewing it, Alexander. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PATCH] LLVM tuple deforming improvements

Hi, Thanks for looking at this! On 2018-07-13 10:20:42 +0200, Pierre Ducroquet wrote: > 2) improve the LLVM IR code > > The code generator in llvmjit-deform.c currently rely on the LLVM optimizer > to > do the right thing. For instance, it can generate a lot of empty blocks with > only a

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

"David G. Johnston" writes: > I think serious consideration needs to be given to ways to allow the user > of pg_dump/pg_restore to choose the prior, less secure, mode of operation​. > IMO the risk surface presented to support back-patching the behavioral > changes was not severe enough to do so

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

On Fri, Jul 13, 2018 at 1:54 PM, Tom Lane wrote: > So this is all pretty messy, but on the bright side, fixing it would allow > cleaning up some ancient squishy coding in ruleutils.c. It wouldn't be > controversial as just a v12 addition, perhaps ... but do we have a choice > about

Re: function lca('{}'::ltree[]) caused DB Instance crash

I wrote: > However, I don't understand why this code is returning NULL, rather than > a zero-length ltree, in the case that there's no common prefix. That > doesn't seem consistent to me. After looking more closely, I see that what lca() returns is the longest common *ancestor* of the input

Re: GiST VACUUM

On 13/07/18 21:28, Andrey Borodin wrote: 13 июля 2018 г., в 18:25, Heikki Linnakangas написал(а): Looking at the second patch, to scan the GiST index in physical order, that seems totally unsafe, if there are any concurrent page splits. In the logical scan, pushStackIfSplited() deals with

Re: [HACKERS] [PATCH] kNN for SP-GiST

Attached  6th version of the patches. On 09.07.2018 20:47, Andrey Borodin wrote: 4 июля 2018 г., в 3:21, Nikita Glukhov написал(а): Attached 5th version of the patches, where minor refactoring of distance handling was done (see below). I'm reviewing this patch. Currently I'm trying to

Re: pgsql: Fix parallel index and index-only scans to fall back to serial.

On Fri, Jul 13, 2018 at 2:22 PM, Heikki Linnakangas wrote: > I just bumped into this comment, from commit 09529a70bb5, and I can't make > sense of it: > >> + /* >> +* We reach here if the index only scan is not parallel, >> or if we're >> +* executing

Re: GSOC 2018 Project - A New Sorting Routine

On Fri, Jul 13, 2018 at 3:04 PM, Kefan Yang wrote: > 1. Slow on CREATE INDEX cases. > > I am still trying to figure out where the bottleneck is. Is the data pattern > in index creation very different from other cases? Also, pg_qsort has > 10%-20% advantage at creating index even on sorted data