Re: [HACKERS] [POC] Faster processing at Gather node

Hi, On 2018-01-25 12:09:23 -0500, Robert Haas wrote: > > Perhaps a short benchmark for 32bit systems using shm_mq wouldn't hurt? > > I suspect there won't be much of a performance impact, but it's probably > > worth checking. > > I don't think I understand your concern here. If this is used on a

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Jan 9, 2018 at 9:49 AM, Masahiko Sawada wrote: >> If I understand correctly, XactLastRecEnd can be set by, for example, >> a HOT cleanup record, so that doesn't seem like a good thing to use. > > Yes, that's right. > >> Whether we need to use 2PC across remote nodes

Re: JIT compiling with LLVM v10.0

On Wednesday, February 7, 2018 3:54:05 PM CET Andres Freund wrote: > Hi, > > I've pushed v10.0. The big (and pretty painful to make) change is that > now all the LLVM specific code lives in src/backend/jit/llvm, which is > built as a shared library which is loaded on demand. > > The layout is

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

On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera wrote: >> Waiting as you say would be akin to what the patch does by putting >> vacuum on its own parallel group. > > I don't think it's the same. We don't need to wait until all the > concurrent tests are done -- we only

Re: Add PGDLLIMPORT to enable_hashagg

Thank you Metin ! Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: JIT compiling with LLVM v10.0

Hi, On 2018-02-07 20:35:12 +0100, Pierre Ducroquet wrote: > I also find it more readable and it looks cleaner, insane guys could be able > to write their own JIT engines for PostgreSQL by patching a single > file :) Right - we could easily make the libname configurable if requested. > Since

Re: PDF Builds on borka (Debian/stretch) broken - 9.6

Stephen Frost writes: > While trying to do the PDF builds on borka for 9.6 for tomorrow's > release, I'm getting: > openjade -D . -D . -c > /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d ./stylesheet.dsl > -t tex -V tex-backend -i output-print -i include-index

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On Wed, Feb 7, 2018 at 6:01 PM, Tom Lane wrote: > Robert Haas writes: >> I spent a while reading through this today. I see a few decisions >> here or there that are debatable, in the sense that somebody else >> might have chosen to do it differently,

Re: PDF Builds on borka (Debian/stretch) broken - 9.6

On 2/7/18 17:21, Stephen Frost wrote: > Looks like Nov 15 (which I believe is when the stretch upgrade was done) > it was upgraded: > > 2017-11-15 17:38:55 upgrade openjade:amd64 1.4devel1-21.1 1.4devel1-21.3+b1 > > That doesn't look like a terribly large version bump to me tho.. You probably

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

Claudio Freire wrote: > On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera > wrote: > >> Waiting as you say would be akin to what the patch does by putting > >> vacuum on its own parallel group. > > > > I don't think it's the same. We don't need to wait until all the > >

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

On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera wrote: > Claudio Freire wrote: >> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera >> wrote: >> >> Waiting as you say would be akin to what the patch does by putting >> >> vacuum on its own parallel

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

Claudio Freire wrote: > On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera > wrote: > > Claudio Freire wrote: > > Hmm, this solution is not very friendly to the goal of reducing test > > runtime, particularly since the new test creates a nontrivial-sized > > table. Maybe

Re: [HACKERS] A design for amcheck heapam verification

On Mon, Feb 5, 2018 at 12:55 PM, Peter Geoghegan wrote: > Anyway, parallel CREATE INDEX added a new "scan" argument to > IndexBuildHeapScan(), which caused this patch to bitrot. At a minimum, > an additional NULL argument should be passed by amcheck. However, I > have a better idea.

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

On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera wrote: > Claudio Freire wrote: > >> - vacuum test on its own parallel group > > Hmm, this solution is not very friendly to the goal of reducing test > runtime, particularly since the new test creates a nontrivial-sized >

Re: update tuple routing and triggers

Thanks for the review. On 2018/02/08 0:04, Robert Haas wrote: > On Tue, Feb 6, 2018 at 12:52 AM, Amit Langote > wrote: >> About renaming es_leaf_result_relations to >> es_tuple_routing_result_relations, I will defer that to committer. But on >> second though,

Re: PostgreSQL crashes with SIGSEGV

On Wed, Feb 7, 2018 at 4:41 PM, Tom Lane wrote: > Peter Geoghegan writes: >> It would be nice to get an opinion on this mode_final() + tuplesort >> memory lifetime business from you, Tom. > > I'm fairly sure that that bit in mode_final() was just a hack to make

Re: Add more information_schema columns

On Wed, Feb 07, 2018 at 10:50:12AM -0500, Peter Eisentraut wrote: > Committed with the separate entries. Thanks. The result looks fine to me. -- Michael signature.asc Description: PGP signature

Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

On Tue, Feb 6, 2018 at 5:21 PM, Peter Eisentraut wrote: > On 9/18/17 22:41, Andres Freund wrote: >> Rearm statement_timeout after each executed query. > > This appears to have broken statement_timeout behavior in master such > that only every second query is

it's a feature, but it feels like a bug

Hi, I've bumped onto the following problem: -screenshot ztk=# create table test (a int, b int, c int, d bool, e int, primary key (a,b,c,d)); CREATE TABLE ztk=# create unique index leftone on test (a,b) where d is true; CREATE INDEX ztk=# create

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Hi Ashutosh. On 2018/02/07 13:51, Ashutosh Bapat wrote: > Here's a new patchset with following changes > > 1. Rebased on the latest head taking care of partition bound > comparison function changes I was about to make these changes myself while revising the fast pruning patch. Instead, I

Re: [HACKERS] Bug in to_timestamp().

> On 6 February 2018 at 10:17, Arthur Zakirov wrote: > It is strange. I still can apply both v9 [1] and v10 [2] via 'git > apply'. And Patch Tester [3] says that it is applied. But maybe > it is because of my git (git version 2.16.1). > > You can try also 'patch -p1':

Re: JIT compiling with LLVM v10.0

On Thu, Feb 8, 2018 at 3:54 AM, Andres Freund wrote: > I've pushed v10.0. The big (and pretty painful to make) change is that > now all the LLVM specific code lives in src/backend/jit/llvm, which is > built as a shared library which is loaded on demand. > > The layout is now

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On Thu, Jan 11, 2018 at 2:58 AM, Etsuro Fujita wrote: > (2017/12/27 20:55), Etsuro Fujita wrote: >> Attached is an updated version of the patch. > > I revised code/comments a little bit. PFA new version. I spent a while reading through this today. I see a few

Re: [HACKERS] More stats about skipped vacuums

Robert Haas writes: > It seems to me that there was a thread where Tom proposed removing > support for dynamic_shared_memory_type = none. I think you're recalling <32138.1502675...@sss.pgh.pa.us>, wherein I pointed out that >>> Whether that's worth the trouble is

Re: PDF Builds on borka (Debian/stretch) broken - 9.6

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > While trying to do the PDF builds on borka for 9.6 for tomorrow's > > release, I'm getting: > > > openjade -D . -D . -c > > /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d > >

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

Claudio Freire wrote: > - vacuum test on its own parallel group Hmm, this solution is not very friendly to the goal of reducing test runtime, particularly since the new test creates a nontrivial-sized table. Maybe we can find a better alternative. Can we use some wait logic instead? Maybe

Re: PDF Builds on borka (Debian/stretch) broken - 9.6

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> We've seen this before, eg >> https://www.postgresql.org/message-id/51CB39BD.8020205%40pgexperts.com >> and the conclusion seemed to be that it was from having the wrong version >> of openjade installed. Was

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

Robert Haas writes: > I spent a while reading through this today. I see a few decisions > here or there that are debatable, in the sense that somebody else > might have chosen to do it differently, but I don't see anything that > actually looks wrong. So, committed. The

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

On Thu, Feb 8, 2018 at 2:44 AM, Kyotaro HORIGUCHI wrote: > Hello, I looked this a bit closer. > > In upthread[1] Robert mentioned the exponentially increasing size > of additional segments. > >>> Hmm, I had imagined making all of the segments the same size rather

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On 2018/02/08 11:55, Amit Langote wrote: > Hi Ashutosh. > > On 2018/02/07 13:51, Ashutosh Bapat wrote: >> Here's a new patchset with following changes >> >> 1. Rebased on the latest head taking care of partition bound >> comparison function changes > > I was about to make these changes myself

Re: [HACKERS] MERGE SQL Statement for PG11

On Wed, Feb 7, 2018 at 10:52 PM, Peter Geoghegan wrote: > > > Apparently there is a pending patch to do better there - the commit > message of 2f178441 refers to this. > > Thanks. Will look at it. > > The revised version also supports subqueries in SET targetlist as well as > >

Fix a typo in walsender.c

Hi, Attached a minor patch for variable name in comment: s/progress_update/update_progress ---include/server/replication/logical.h ... 35 typedef struct LogicalDecodingContext 36 { ... 68 LogicalOutputPluginWriterUpdateProgress update_progress; Regards, -- Atsushi Torikoshi

Re: JIT compiling with LLVM v10.0

On 2018-02-08 11:50:17 +1300, Thomas Munro wrote: > You are asking LLVM to dlopen(""), which doesn't work on my not-Linux, > explaining the errors I reported in the older thread. The portable > way to dlopen the main binary is dlopen(NULL), so I think you need to > pass NULL in to

Re: it's a feature, but it feels like a bug

Rafal Pietrak writes: > ztk=# create table test (a int, b int, c int, d bool, e int, primary key > (a,b,c,d)); > CREATE TABLE > ztk=# create unique index leftone on test (a,b) where d is true; > CREATE INDEX > ztk=# create unique index rightone on test (b,c) where d is

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

On Thu, Feb 8, 2018 at 12:13 AM, Claudio Freire wrote: > On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera > wrote: >> Claudio Freire wrote: >>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera >>> wrote: >>> >> Waiting as

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

(2018/02/08 10:40), Robert Haas wrote: On Wed, Feb 7, 2018 at 6:01 PM, Tom Lane wrote: The buildfarm's opinion of it is lower than yours. Just eyeballing the failures, I'd say there was some naivete about the reproducibility of tuple CTIDs across different platforms. Is

Re: [HACKERS] path toward faster partition pruning

On 2018/02/07 1:36, Robert Haas wrote: > On Tue, Feb 6, 2018 at 4:55 AM, Amit Langote > wrote: >>> I understand why COLLATION_MATCH think that a collation OID match is >>> OK, but why is InvalidOid also OK? Can you add a comment? Maybe some >>> test cases, too? >>

Re: SSL test names

On Wed, Feb 07, 2018 at 11:54:52AM -0500, Peter Eisentraut wrote: > Here is a patch that gives the tests in the SSL test suite proper names > instead of just writing out the connection strings. So instead of > > # running client tests > # test that the server doesn't accept non-SSL connections >

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire wrote: > On Tue, Feb 6, 2018 at 4:56 AM, Masahiko Sawada wrote: >> On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire >> wrote: >>> On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada

Re: it's a feature, but it feels like a bug

On Wed, Feb 07, 2018 at 10:26:50PM -0500, Tom Lane wrote: > Rafal Pietrak writes: > > ztk=# create table test (a int, b int, c int, d bool, e int, primary key > > (a,b,c,d)); > > CREATE TABLE > > ztk=# create unique index leftone on test (a,b) where d is true; > >

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

Hello, I looked this a bit closer. In upthread[1] Robert mentioned the exponentially increasing size of additional segments. >> Hmm, I had imagined making all of the segments the same size rather >> than having the size grow exponentially. The whole point of this is >> to save memory, and even

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

(2018/02/08 5:39), Robert Haas wrote: On Thu, Jan 11, 2018 at 2:58 AM, Etsuro Fujita wrote: (2017/12/27 20:55), Etsuro Fujita wrote: Attached is an updated version of the patch. I revised code/comments a little bit. PFA new version. I spent a while reading

Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support

Hi all, In order to run tests consistently on the whole tree, I use a simple alias which tests also things like src/test/ssl and src/test/ldap on the way. Lately, I am getting annoyed by $subject when working on OpenSSL stuff as sometimes I need to test things with and without SSL support to

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Sun, Feb 4, 2018 at 6:10 PM, Tom Lane wrote: > Oliver Ford writes: > > [ 0001-window-frame-v13.patch ] > > I've been hacking on this all week (with breaks for release notes) and > have gotten it into a state that I think is close to committable. > >

In logical replication concurrent update of partition key creates a duplicate record on standby.

Hi, If an update of partition key involves tuple movement from one partition to another partition then there will be a separate delete on one partition and insert on the other partition made. In the logical replication if an update performed on the master and standby at the same moment, then

Re: MCV lists for highly skewed distributions

On 1 February 2018 at 17:49, Robert Haas wrote: > One point which I want to emphasize is that the length of the MCV list > bounds the estimated frequency of non-MCVs in two ways: no non-MCV is > ever thought to be more frequent than the least-common MCVs, and > however many

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Dec 22, 2017 at 3:00 PM, Rajkumar Raghuwanshi wrote: > On Wed, Dec 20, 2017 at 5:21 PM, Ashutosh Bapat > wrote: >> >> Thanks. Here are some comments >> > Thanks Ashutosh for review and suggestions. > >> >> +-- test

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: > On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: >> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: >>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila

Re: In logical replication concurrent update of partition key creates a duplicate record on standby.

On 7 February 2018 at 13:53, amul sul wrote: > Hi, > > If an update of partition key involves tuple movement from one partition to > another partition then there will be a separate delete on one partition and > insert on the other partition made. > > In the logical replication

Re: MCV lists for highly skewed distributions

On 4 February 2018 at 12:18, John Naylor wrote: > I did the same basic eyeball testing I did on earlier patches, and > this is the best implementation so far. I've attached some typical > pg_stats contents for HEAD and this patch. More rigorous testing, > including of planner

Re: git instructions

On Tue, Feb 6, 2018 at 9:59 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, Feb 6, 2018 at 1:46 PM, Stefan Kaltenbrunner < > ste...@kaltenbrunner.cc> wrote: > >> >> > >> > Yes, this used to be the case, and is the reason behind the original >> > recommendation. It's what they

Re: In logical replication concurrent update of partition key creates a duplicate record on standby.

On Wed, Feb 7, 2018 at 3:03 PM, Amit Khandekar wrote: > On 7 February 2018 at 13:53, amul sul wrote: >> Hi, >> >> If an update of partition key involves tuple movement from one partition to >> another partition then there will be a separate delete on

Re: non-bulk inserts and tuple routing

(2018/02/05 19:43), Etsuro Fujita wrote: (2018/02/05 14:34), Amit Langote wrote: The code in tupconv_map_for_subplan() currently assumes that it can rely on all leaf partitions having been initialized. On reflection I noticed this analysis is not 100% correct; I think what that function

ERROR: could not map dynamic shared memory segment

Hi , I am getting  ERROR:  could not map dynamic shared memory segment in the log file - Please refer this scenario- in V11/V10 latest sources  set parallel_setup_cost=0;  set parallel_tuple_cost=0;  set max_parallel_workers_per_gather=4;  create table r(n int); insert into r values

Re: Incorrect grammar

(2018/02/07 5:51), Robert Haas wrote: On Tue, Feb 6, 2018 at 5:22 AM, Etsuro Fujita wrote: While reviewing the lazy-initialization-of-partition-info-for-tuple-routing patch, I ran into a grammar mistake in a comment in ExecSetupChildParentMapForLeaf. Attached is a

Re: ERROR: could not map dynamic shared memory segment

On Wed, Feb 7, 2018 at 11:42 PM, tushar wrote: > I am getting ERROR: could not map dynamic shared memory segment in the log > file > > - Please refer this scenario- > > in V11/V10 latest sources > > set parallel_setup_cost=0; > set parallel_tuple_cost=0; > set

Re: Add PGDLLIMPORT to enable_hashagg

Hey all, I'm attaching the updated patch, it includes i. The list of Pascal (max_worker_processes was already with PGDLLIMPORT, so I also added to max_parallel_workers) ii. Some others in cost.h to make the file more readable. Best, Metin On Tue, Feb 6, 2018 at 10:40 PM, Peter Geoghegan

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Feb 3, 2018 at 4:04 AM, Robert Haas wrote: > On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila wrote: >> So, this means that in case of logical replication, it won't generate >> the error this patch is trying to introduce. I think if we want to

Re: In logical replication concurrent update of partition key creates a duplicate record on standby.

On 7 February 2018 at 17:33, Amit Khandekar wrote: > > A quick thinking on how to resolve this makes me wonder if we can > manage to pass some information through logical decoding that the > delete is part of a partition key update. This is analogous to how we > set some

Re: MCV lists for highly skewed distributions

On Wed, Feb 7, 2018 at 3:51 AM, Dean Rasheed wrote: > Thanks for testing. I agree, this new algorithm seems to stand up > pretty well in the testing I've done too. One thing about it that can > be tuned is the cutoff threshold for the relative standard error -- I > chose

Re: [HACKERS] path toward faster partition pruning

On Wed, Feb 7, 2018 at 6:49 PM, Robert Haas wrote: > On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat > wrote: >> partprune.c looks to much tied to one feature. I am sure that the >> functions used for partition pruning can be used by other

Re: Obsolete fmgr() declaration in fmgr.h

On Tue, Feb 6, 2018 at 9:37 AM, Dagfinn Ilmari Mannsåker wrote: > Commit 5ded4bd21403e143dd3eb66b92d52732fdac1945 removed support for > version-0 function calling convention, and with it the fmgr() function. > However, the declaration was left behind in fmgr.h. The attached

Re: [HACKERS] path toward faster partition pruning

On Wed, Feb 7, 2018 at 8:37 AM, Ashutosh Bapat wrote: > While looking at the changes in partition.c I happened to look at the > changes in try_partition_wise_join(). They mark partitions deemed > dummy by pruning as dummy relations. If we accept those changes, we

Re: Why does load_external_function() return PGFunction?

Andres Freund writes: > On 2018-02-06 15:43:29 -0500, Tom Lane wrote: >> void* isn't necessarily compatible with function pointers --- there are >> platforms where they're physically different widths, though possibly >> you'd never get PG to run on such hardware anyway. >

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

On Wed, Feb 7, 2018 at 12:50 AM, Kyotaro HORIGUCHI wrote: > Hello, > > At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire > wrote in

Re: Obsolete fmgr() declaration in fmgr.h

Robert Haas writes: > On Tue, Feb 6, 2018 at 9:37 AM, Dagfinn Ilmari Mannsåker > wrote: >> Commit 5ded4bd21403e143dd3eb66b92d52732fdac1945 removed support for >> version-0 function calling convention, and with it the fmgr() function. >> However, the

Re: JIT compiling with LLVM v10.0

Hi, I've pushed v10.0. The big (and pretty painful to make) change is that now all the LLVM specific code lives in src/backend/jit/llvm, which is built as a shared library which is loaded on demand. The layout is now as follows: src/backend/jit/jit.c: Part of JITing always linked into the

Re: Re: [HACKERS] WIP: Separate log file for extension

Hi Antonin, On 1/10/18 5:38 PM, Tom Lane wrote: > Antonin Houska writes: >> After having read the thread on your patch I think that the reason you were >> asked to evaluate performance was that your patch can possibly make syslogger >> a bottleneck. In contrast, my patch does

Re: update tuple routing and triggers

On Tue, Feb 6, 2018 at 12:52 AM, Amit Langote wrote: > About renaming es_leaf_result_relations to > es_tuple_routing_result_relations, I will defer that to committer. But on > second though, maybe we don't need to make this patch larger than it has > to be. +1 for

Re: MCV lists for highly skewed distributions

On Wed, Feb 7, 2018 at 10:20 AM, Dean Rasheed wrote: > One thing this new algorithm does do is improve the user's ability to > get more MCVs by increasing the stats target. I'm not yet convinced > there should be a separate knob for the RSE cutoff. For that to be >

Re: Re: [HACKERS] Proposal: generic WAL compression

Hi Oleg, On 1/22/18 4:37 PM, Stephen Frost wrote: > Oleg, > > I'm not really sure why this is still in Needs Review as a review was > posted and I don't see any follow-up. I've changed this to be Waiting > for Author. > > * Antonin Houska (a...@cybertec.at) wrote: >> Oleg Ivanov

Re: Re: New gist vacuum.

Hi Andrey, On 1/21/18 5:34 AM, Andrey Borodin wrote: > Hello, Alexander! >> 16 янв. 2018 г., в 21:42, Andrey Borodin написал(а): >> Please find README patch attached. > > Here's v2 version. Same code, but x2 comments. Also fixed important typo in > readme BFS->DFS. Feel

Re: New gist vacuum.

Hi, David! > 7 февр. 2018 г., в 18:39, David Steele написал(а): > > Hi Andrey, > > On 1/21/18 5:34 AM, Andrey Borodin wrote: >> Hello, Alexander! >>> 16 янв. 2018 г., в 21:42, Andrey Borodin написал(а): >>> Please find README patch attached. >> >>

Re: [HACKERS] [PATCH] Improve geometric types

> - line_eq looks too complex in the normal (not containing NANs) >cases. We should avoid such complexity if possible. > >One problem here is that comparison conceals NANness of >operands. Conversely arithmetics propagate it. We can converge >NANness into a number. The attached

Re: MCV lists for highly skewed distributions

On 7 February 2018 at 15:25, Robert Haas wrote: > Do you plan to press forward with this, then, or what's > the next step? > Yes, I think the results are pretty good so far, especially for the more non-uniform distributions. AFAICS it solves the 2 original complaints, and

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On Mon, Jan 22, 2018 at 7:05 AM, Amit Kapila wrote: > On error, workers should be terminated. What kind of problem do you > have in mind? Hmm. Yeah, I guess that makes sense. If the only thing you can do is fetch from the cursor -- and you have to make sure to lock

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Tue, Feb 6, 2018 at 6:03 PM, Michael Paquier wrote: > I am not sure that we would like to give up that easily the property > that we have now to clean up past temporary files only at postmaster > startup and only when not in recovery. If you implement that, there is

Re: [PROPOSAL] Shared Ispell dictionaries

On Thu, Jan 25, 2018 at 07:51:58PM +0300, Arthur Zakirov wrote: > Attached new version of the patch. Here is rebased version of the patch due to changes into dict_ispell.c. The patch itself wasn't changed. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres

SSL test names

Here is a patch that gives the tests in the SSL test suite proper names instead of just writing out the connection strings. So instead of # running client tests # test that the server doesn't accept non-SSL connections ok 1 - sslmode=disable (should fail) # connect without server root cert ok 2

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Tue, Feb 6, 2018 at 7:51 AM, Claudio Freire wrote: > No free space becomes visible during long-running vacuums. That means > bloat keeps accumulating even though vacuum is freeing space, because > the FSM doesn't expose that free space. > > The extra work incurred in

Re: [HACKERS] More stats about skipped vacuums

On Tue, Feb 6, 2018 at 8:34 PM, Kyotaro HORIGUCHI wrote: > Based on the reason, it fails to run when > dynamic_shared_memory_type = none and it is accompanied by > several cleanup complexities. The decision there is we should go > for just using static shared

Re: [HACKERS] path toward faster partition pruning

On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat wrote: > partprune.c looks to much tied to one feature. I am sure that the > functions used for partition pruning can be used by other > optimizations as well. Uh, I don't know about that, this code looks like it

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Tue, Feb 6, 2018 at 7:05 PM, amul sul wrote: > On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila wrote: >> On Fri, Feb 2, 2018 at 2:11 PM, amul sul wrote: >>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila

Re: In logical replication concurrent update of partition key creates a duplicate record on standby.

On Wed, Feb 7, 2018 at 3:42 PM, amul sul wrote: > On Wed, Feb 7, 2018 at 3:03 PM, Amit Khandekar wrote: >> On 7 February 2018 at 13:53, amul sul wrote: >>> Hi, >>> >>> If an update of partition key involves tuple movement from one