Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

Hello, This patch enables building pgbench to use ppoll() instead of select() to allow for more than (FD_SETSIZE - 10) connections. As implemented, when using ppoll(), the only connection limitation is system resources. I'm fine with allowing more clients through ppoll, as large

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Tue, Nov 28, 2017 at 9:37 PM, Robert Haas wrote: > On Mon, Nov 27, 2017 at 6:54 AM, Amit Kapila wrote: >>> Anything "below" "Gather"? >>> >> I think it is "actual_time * 1" for anything below Gather. > > The actual time amounts below Gather show

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Tue, Nov 28, 2017 at 9:42 PM, Robert Haas wrote: > On Tue, Nov 28, 2017 at 2:23 AM, Amit Kapila wrote: >> That is wrong and I think you have hit a bug. It should be 2974 * 5 = >> 14870 as you have seen in other cases. The problem is that

Re: [HACKERS] Runtime Partition Pruning

Hello Rajkumar, On Tue, Nov 14, 2017 at 2:22 PM, Rajkumar Raghuwanshi wrote: > On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson > wrote: >> >> PFA the updated patches. > > > Hi, > > I have started testing this along with fast

Re: [HACKERS] postgres_fdw super user checks

On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote: > > Just to make it clear, I continue to agree with (3) and agree with Tom > that we shouldn't be behaving differently depending on who is calling > the view. I also would vote for 3. That looks consistent with the way we

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

> 29 нояб. 2017 г., в 15:59, Alexander Korotkov > написал(а): > > > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. > Since, these patches include bug fix, it's possible that someone will commit > it before next

Re: Skip index cleanup if autovacuum did not do any work

On 28 November 2017 at 23:17, Peter Geoghegan wrote: > BTW, a good short term solution for you might be to change the vacuum > cost delay settings. They're pretty conservative by default. > > There is a good chance that your indexes are mostly in memory even on > large tables, and

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

On Wed, Nov 29, 2017 at 7:51 AM, Amit Kapila wrote: > On Tue, Nov 28, 2017 at 5:58 PM, amul sul wrote: >> On Sat, Nov 25, 2017 at 11:39 AM, Amit Kapila >> wrote: >>> On Thu, Nov 23, 2017 at 5:18 PM, amul sul

Re: [HACKERS] Runtime Partition Pruning

Hello, PFA the new version of the patch which can be applied over v11 patches of Amit Langote [1]. The patch has been completely modified and the 0001 patch of previous series is no longer required. As mentioned above, I have used the PartitionDispatchInfo and an array to which holds the actual

Re: [HACKERS] Runtime Partition Pruning

On Tue, Nov 14, 2017 at 6:27 PM, David Rowley wrote: > On 14 November 2017 at 19:16, Beena Emerson wrote: >> PFA the updated patches. > > Hi Beena, > > Thanks for working on this. I've had a look at the patch to try to > understand how it is

Re: [HACKERS] Runtime Partition Pruning

Hello, On Wed, Nov 15, 2017 at 4:43 AM, David Rowley wrote: > On 15 November 2017 at 01:57, David Rowley > wrote: >> I think to do this you're going to have to store some sort of array >> that maps the partition index to the subpath

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On 11/29/2017 06:13 AM, Michael Paquier wrote: > On Tue, Nov 21, 2017 at 7:07 AM, Alexander Korotkov > wrote: >> On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov >> wrote: >>> >>> On Mon, Nov 20, 2017 at 4:09 AM, Tomas Vondra >>>

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 1:30 PM, Tomas Vondra wrote: > On 11/29/2017 06:13 AM, Michael Paquier wrote: > > On Tue, Nov 21, 2017 at 7:07 AM, Alexander Korotkov > > wrote: > >> On Mon, Nov 20, 2017 at 1:59 PM, Alexander Korotkov > >>

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

Hi! On Wed, Nov 29, 2017 at 2:32 PM, Andrey Borodin wrote: > 29 нояб. 2017 г., в 15:59, Alexander Korotkov > написал(а): > > > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. > Since, these

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 7:59 PM, Alexander Korotkov wrote: > Sure, patch got some review. I've no objection against moving this to the > next commitfest though. Please note that as this is qualified as a bug fix, I was not going to mark it as returned with feedback or

Re: [HACKERS] postgres_fdw super user checks

Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote: > > The "global rethink" being contemplated seems to be more about > > authentication forwarding than it is about this specific change. If > > there's

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

[...] Yeah, that sort of style would be OK with me. But I wouldn't like: struct blah { #ifdef FOO int doohicky; #else char *doohicky; }; Indeed. Me neither. -- Fabien.

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

On Wed, Nov 29, 2017 at 3:40 AM, Fabien COELHO wrote: > ever is best. Not sure that "pfds" is the right name. If the two variables > means the same thing, they should have the same name, although possibly > different types. Although I agree with a good bit of what you say

Re: using index or check in ALTER TABLE SET NOT NULL

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Nov 28, 2017 at 1:59 PM, Sergei Kornilov wrote: > > I write patch to speed up ALTER TABLE SET NOT NULL by check existed check > > constraints or indexes. Huge phase 3 with verify table data will be skipped > > if

Re: using index or check in ALTER TABLE SET NOT NULL

On Wed, Nov 29, 2017 at 10:52 AM, Sergei Kornilov wrote: > I agree this. Thinking a little about idea of index scan i can not give > reasonable usecase which required index. My target problem of adding NOT NULL > to big relation without long downtime can be done with ADD

Re: using index or check in ALTER TABLE SET NOT NULL

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Isn't the first concern addressed by using SPI..? > > I did not look at the patch yet, but TBH if it uses SPI for sub-operations > of ALTER TABLE I think that is sufficient reason to reject it out of

Re: [HACKERS] Issues with logical replication

Hi, (sorry for not being active here, I am still catching up after being away for some family issues) On 16/11/17 21:12, Robert Haas wrote: > On Thu, Nov 16, 2017 at 2:41 PM, Andres Freund wrote: >>> To me, it seems like SnapBuildWaitSnapshot() is fundamentally >>>

Re: new function for tsquery creartion

On 2017-11-29 17:56, Victor Drobny wrote: Sorry, forgot to attach new version of the patch. On 2017-11-28 17:57, Aleksander Alekseev wrote: Hi Aleksander, Thank you for review. I have tried to fix all of your comments. However i want to mention that the absence of comments for functions in

Re: es_query_dsa is broken

On Wed, Nov 29, 2017 at 7:30 AM, Thomas Munro wrote: > While reviewing commit c6755e23 I realised that es_query_dsa is > broken. It might have made some kind of sense as a name and a concept > in an earlier version of the proposal to add a DSA area for parallel >

Re: [HACKERS] Walsender timeouts and large transactions

Hi, On 17/11/17 08:35, Kyotaro HORIGUCHI wrote: > > Moving around the code allow us to place ps_is_send_pending() in > the while condition, which seems to be more proper place to do > that. I haven't added test for this particular case. > > I tested this that > > - cleanly applies on the

Re: using index or check in ALTER TABLE SET NOT NULL

On November 29, 2017 8:50:31 AM PST, Stephen Frost wrote: >As for conflicting snapshots, isn't the lock we're taking already >AccessExclusive..? Doesn't help if e.g. the current xact is repeatable read or if your own xact deleted things (other xacts with snapshots could

Re: using index or check in ALTER TABLE SET NOT NULL

Here is new patch with check only existed valid constraints and without SPI at all. Thanksdiff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index d979ce2..7ab7580 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -370,6 +370,8

Re: using index or check in ALTER TABLE SET NOT NULL

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I did not look at the patch yet, but TBH if it uses SPI for sub-operations >> of ALTER TABLE I think that is sufficient reason to reject it out of hand. > You mean like what ALTER TABLE ... ADD FOREIGN KEY

Re: [HACKERS] WIP: Restricting pg_rewind to data/wal dirs

On 11/29/17 12:46 AM, Michael Paquier wrote:> On Wed, Nov 1, 2017 at 5:58 PM, Chris Travers wrote: > > Please note that I am still -1 for using a methodology different than > what is used for base backups with an inclusive method, and would much > prefer an exclusive

Re: [HACKERS] static assertions in C++

Andres Freund writes: > On 2017-11-29 16:39:14 -0500, Tom Lane wrote: >> Andres Freund writes: >>> FWIW, I think that's a perfectly reasonable choice. Adding complications >>> in making static assertions work for random archaic compilers when >>> compiling

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 29 Nov 2017, at 04:29, Michael Paquier wrote: > > On Tue, Nov 28, 2017 at 10:07 AM, Michael Paquier > wrote: >> I was just looking at the tsearch code which uses pg_strcmpcase, and >> those are defined with makeDefElem() so you should

Re: [HACKERS] path toward faster partition pruning

On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas wrote: > On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote > wrote: >> It seems I wrote an Assert in the code to support hash partitioning that >> wasn't based on a valid assumption. I was wrongly

Re: [HACKERS] static assertions in C++

Andres Freund writes: > On 2017-11-29 09:41:15 -0500, Robert Haas wrote: >> +/* not worth providing a workaround */ > FWIW, I think that's a perfectly reasonable choice. Adding complications > in making static assertions work for random archaic compilers when > compiling with

Re: [HACKERS] Parallel Hash take II

On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro wrote: > On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro > wrote: >> Here's a new patch set with responses to the last batch of review comments. > > Rebased on top of the recent SGML->XML

Re: [HACKERS] Cached plans and statement generalization

On Wed, Sep 13, 2017 at 2:11 AM, Konstantin Knizhnik wrote: > One more patch passing all regression tests with autoprepare_threshold=1. > I still do not think that it should be switch on by default... This patch does not apply, and did not get any reviews. So I am

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

On Thu, Nov 9, 2017 at 12:33 PM, Ashutosh Bapat wrote: > Looking at order_qual_clauses(), we can say that a set of quals q1 > qn are ordered the same irrespective of the set of clauses they > are subset of. E.g. if {q1 .. qn} is subset of Q (ordered as Qo)

Re: [HACKERS] Proposal: generic WAL compression

On Mon, Nov 20, 2017 at 4:49 PM, Antonin Houska wrote: > One more idea: > > I think the metadata (ALIGN_GAP) should be stored separate from the actual > data so that you can use memcpy() instead of this loop: > > while (i < j) > { > charc =

Re: [HACKERS] create_unique_path and GEQO

On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane wrote: > Ashutosh Bapat writes: >>> Do you have test case, which can reproduce the issue you >>> explained above? > >> No. It would require some surgery in standard_planner() to measure the >> memory

Re: [HACKERS] INSERT .. ON CONFLICT DO SELECT [FOR ..]

On Wed, Nov 29, 2017 at 8:34 PM, Michael Paquier wrote: > The patch does not currently apply. I am noticing as well that Peter > Geoghegan has registered himself as a reviewer a couple of hours back, > so moved to next CF with waiting on author as status. Marko

Re: [HACKERS] Issues with logical replication

On 2017-11-30 00:45:44 +0100, Petr Jelinek wrote: > I don't understand. I mean sure the SnapBuildWaitSnapshot() can live > with it, but the problematic logic happens inside the > XactLockTableInsert() and SnapBuildWaitSnapshot() has no way of > detecting the situation short of reimplementing the >

Re: [HACKERS] postgres_fdw: Add support for INSERT OVERRIDING clause

On Wed, Nov 29, 2017 at 1:53 PM, Michael Paquier wrote: > On Wed, Nov 29, 2017 at 8:12 AM, Tom Lane wrote: >> IIRC, this issue was debated at great length back when we first put >> in foreign tables, because early drafts of postgres_fdw did what you

Re: [HACKERS] Removing LEFT JOINs in more cases

On Wed, Nov 22, 2017 at 10:30 PM, Ashutosh Bapat wrote: > On Wed, Nov 1, 2017 at 5:39 AM, David Rowley > wrote: > >> In this case, the join *can* cause row duplicates, but the distinct or >> group by would filter these out again

Re: [HACKERS] Custom compression methods

On Thu, Nov 30, 2017 at 8:30 AM, Tomas Vondra wrote: > On 11/28/2017 02:29 PM, Ildus Kurbangaliev wrote: >> On Mon, 27 Nov 2017 18:20:12 +0100 >> Tomas Vondra wrote: >> >>> I guess the trick might be -DRANDOMIZE_ALLOCATED_MEMORY (I

Re: [HACKERS] INSERT .. ON CONFLICT DO SELECT [FOR ..]

On Tue, Sep 5, 2017 at 3:28 AM, Marko Tiikkaja wrote: > On Mon, Sep 4, 2017 at 7:46 PM, Peter Geoghegan wrote: >> >> On Mon, Sep 4, 2017 at 10:05 AM, Marko Tiikkaja wrote: >> >> > But I'm generally against >> > interfaces which put arbitrary

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Wed, Nov 1, 2017 at 1:20 PM, Andreas Karlsson wrote: > Here is a rebased version of the patch. The patch does not apply, and needs a rebase. I am moving it to next CF with waiting on author as status. -- Michael

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jun 28, 2017 at 9:58 AM, Thomas Munro wrote: > Rebased for the recent re-indent and shm_toc API change; no functional > changes in this version. > > (I have a new patch set in the pipeline adding the skew optimisation > and some other things, more on that

Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)

On Tue, Sep 12, 2017 at 9:48 PM, Tom Lane wrote: > Jim Nasby writes: >> I've verified that the patch still applies and make check-world is clean. > > Not any more :-(. Here's a v3 rebased over HEAD. No substantive > change from v2. Patch applies and

Re: [HACKERS] <> join selectivity estimate question

On Thu, Sep 14, 2017 at 2:23 PM, Ashutosh Bapat wrote: > Are you referring to rounding errors? We should probably add some fuzz > factor to cover the rounding errors and cause a diff when difference > in expected and reported plan rows is beyond that fuzz factor.

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Thu, Nov 30, 2017 at 10:52 AM, Michael Paquier wrote: > On Wed, Nov 29, 2017 at 5:33 AM, Robert Haas wrote: >> On Sun, Nov 26, 2017 at 9:33 PM, Masahiko Sawada >> wrote: >>> Attached latest patch incorporated all

Re: [HACKERS] [PATCH] Call RelationDropStorage() for broader range of object drops.

On Fri, Sep 15, 2017 at 4:36 AM, Alexander Korotkov wrote: > +1, > FDW looks OK for prototyping pluggable storage, but it doesn't seem suitable > for permanent implementation. > BTW, Hadi, could you visit "Pluggable storage" thread and check how suitable > upcoming

Re: Protect syscache from bloating with negative cache entries

On Wed, Nov 29, 2017 at 8:25 PM, Michael Paquier wrote: > On Tue, Oct 31, 2017 at 6:46 PM, Kyotaro HORIGUCHI > wrote: >> This is a rebased version of the patch. > > As far as I can see, the patch still applies, compiles, and got no >

Re: [HACKERS] postgres_fdw bug in 9.6

On Thu, Nov 30, 2017 at 7:32 AM, Tom Lane wrote: > [snip] Moving to next CF per the hotness of the topic. -- Michael

Re: WIP: BRIN multi-range indexes

On Sun, Nov 19, 2017 at 5:45 AM, Tomas Vondra wrote: > Apparently there was some minor breakage due to duplicate OIDs, so here > is the patch series updated to current master. Moved to CF 2018-01. -- Michael

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On Mon, Nov 27, 2017 at 11:41 AM, Jing Wang wrote: > Hi All, > > This is a patch for current_database working on ALTER ROLE/GRANT/REVOKE > statements which should be applied after the previous patch > "comment_on_current_database_no_pgdump_v4.4.patch". > > By using the

Re: [HACKERS] Dynamic result sets from procedures

On Thu, Nov 16, 2017 at 8:27 PM, Daniel Verite wrote: > Peter Eisentraut wrote: > >> There is also one need error that needs further investigation. > > I've looked at this bit in the regression tests about \gexec: > > --- a/src/test/regress/expected/psql.out > +++

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On Fri, Aug 25, 2017 at 6:25 PM, David Rowley wrote: > I just had a quick glance over this and wondered about 2 things. > > 1. Why a GUC and not a new per user option so it can be configured > differently for different users? Something like ALTER USER ... WORKER >

Re: Use of uninitialized variables in ExecFindPartition() for parent partition without leaves (HEAD only)

On 2017/11/30 10:11, Amit Langote wrote: > in the attached updated version. Oops, I messed up taking the diff and mistakenly added noise to the patch. Fixed in the attached. Thanks, Amit diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c index

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 5:28, Robert Haas wrote: > On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote > wrote: >> It seems I wrote an Assert in the code to support hash partitioning that >> wasn't based on a valid assumption. I was wrongly assuming that all hash >> partitions for

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

On Sun, Nov 26, 2017 at 5:15 PM, Amit Kapila wrote: > Yeah and I think something like that can happen after your patch > because now the memory for tuples returned via TupleQueueReaderNext > will be allocated in ExecutorState and that can last for long. I > think it is

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

On Thu, Nov 2, 2017 at 11:35 AM, Robert Haas wrote: > On Thu, Nov 2, 2017 at 8:01 AM, Craig Ringer wrote: >> That forces materialization, and I'm guessing part of Tomas's goal >> here is to prevent the need to materialize into a temp table / >>

Re: [HACKERS] postgres_fdw super user checks

On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost wrote: > Ashutosh, > > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: >> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote: >> > The "global rethink" being contemplated seems to be more about >>

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

On Mon, Oct 2, 2017 at 7:52 AM, Tom Lane wrote: > I wrote: >> This patch no longer applies cleanly on HEAD, so here's a rebased version >> (no substantive changes). As before, I think the most useful review task >> would be to quantify whether it makes planning noticeably

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Oct 31, 2017 at 9:42 PM, Ants Aasma wrote: > Robert made a good point that people will still rely on the token > being an LSN, but perhaps they will be slightly less angry when we > explicitly tell them that this might change in the future. This thread has stalled, I

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Tue, Nov 21, 2017 at 6:36 PM, Peter Moser wrote: > 2017-11-14 18:42 GMT+01:00 Tom Lane : >> You might consider putting the rewriting into, um, the rewriter. >> It could be a separate pass after view expansion, if direct integration >> with the existing

Re: [HACKERS] plpgsql - additional extra checks

On Wed, Sep 13, 2017 at 12:51 PM, Pavel Stehule wrote: > > > 2017-09-13 1:42 GMT+02:00 Daniel Gustafsson : >> >> > On 08 Apr 2017, at 15:46, David Steele wrote: >> > >> >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote: >> >>> On Fri, Jan

Re: Protect syscache from bloating with negative cache entries

On Thu, Nov 30, 2017 at 12:32 PM, Robert Haas wrote: > On Wed, Nov 29, 2017 at 8:25 PM, Michael Paquier > wrote: >> On Tue, Oct 31, 2017 at 6:46 PM, Kyotaro HORIGUCHI >> wrote: >>> This is a rebased version of

Re: [HACKERS] Flexible configuration for full-text search

On Tue, Nov 7, 2017 at 3:18 PM, Aleksandr Parfenov wrote: > On Mon, 6 Nov 2017 18:05:23 +1300 > Thomas Munro wrote: > >> On Sat, Oct 21, 2017 at 1:39 AM, Aleksandr Parfenov >> wrote: >> > In attachment updated

Re: pl/perl extension fails on Windows

On Thu, Nov 30, 2017 at 1:34 PM, Tom Lane wrote: > Noah Misch writes: >> On Thu, Aug 17, 2017 at 12:15:58PM -0400, Tom Lane wrote: >>> ... it's now looking to me like we should do the above with X = 5.13.4. >>> That won't be a perfect solution, but it's

Re: [HACKERS] logical decoding of two-phase transactions

Hi, On 24/11/17 07:41, Craig Ringer wrote: > On 24 November 2017 at 13:44, Nikhil Sontakke   > > > How practical is adding a lock class? > > Am open to suggestions. This looks like it could work decently. > > > It looks amazingly simple from here. Which

Re: [HACKERS] Issues with logical replication

On 2017-11-30 00:25:58 +0100, Petr Jelinek wrote: > Yes that helps thanks. Now that I reproduced it I understand, I was > confused by the backtrace that said xid was 0 on the input to > XactLockTableWait() but that's not the case, it's what xid is changed to > in the inner loop. > So what happens

Re: [HACKERS] Issues with logical replication

On 30/11/17 00:40, Andres Freund wrote: > On 2017-11-30 00:25:58 +0100, Petr Jelinek wrote: >> Yes that helps thanks. Now that I reproduced it I understand, I was >> confused by the backtrace that said xid was 0 on the input to >> XactLockTableWait() but that's not the case, it's what xid is

Use of uninitialized variables in ExecFindPartition() for parent partition without leaves (HEAD only)

Hi all, Since commit 4e5fe9ad (committer Robert Haas and author Amit Langote), coverity has been complaining that the new code of ExecFindPartition() may use a set of values and isnull values which never get initialized. This is a state which can be easily reached with the following SQLs of a

RE: [HACKERS] Cached plans and statement generalization

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > This patch does not apply, and did not get any reviews. So I am moving it > to next CF with waiting on author as status. Please provide a rebased version. > Tsunakawa-san, you are listed as a reviewer of this patch. If you are not >

Re: [HACKERS] Partition-wise aggregation/grouping

On Tue, Nov 28, 2017 at 5:50 PM, Jeevan Chalke wrote: > [snip] This is still a hot topic so I am moving it to next CF. -- Michael

Re: [HACKERS] compress method for spgist - 2

On Fri, Sep 22, 2017 at 9:03 AM, Nikita Glukhov wrote: > Should I start a separate thread for this issue and add patches to > commitfest? Yes, please. It would be nice if you could spawn a separate thread for what looks like a bug, and separate topics should have their

Re: [HACKERS] Parallel Hash take II

On 2017-11-30 14:17:51 +1300, Thomas Munro wrote: > On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro > wrote: > > On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro > > wrote: > >> Here's a new patch set with responses to the last batch of

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 11:18, Michael Paquier wrote: > On Thu, Nov 30, 2017 at 10:43 AM, Amit Langote > wrote: >> I'm working on a revised version of these patches to address recent >> comments by Horiguchi-san. I will also consider the points above before >> sending the

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 30 November 2017 at 15:34, Michael Paquier wrote: > On Wed, Nov 15, 2017 at 3:17 PM, David Rowley > wrote: > > The remove_singleton_appends_examples_of_differences_2017-11-15.patch > > which I've attached applies changes to the

Re: [HACKERS] Subscription code improvements

On Fri, Aug 18, 2017 at 2:09 PM, Masahiko Sawada wrote: > On Thu, Aug 17, 2017 at 8:17 PM, Masahiko Sawada > wrote: >> On Thu, Aug 17, 2017 at 9:10 AM, Peter Eisentraut >> wrote: >>> On 8/8/17 05:58, Masahiko

Re: [HACKERS] Replication status in logical replication

On Wed, Nov 22, 2017 at 6:06 AM, Masahiko Sawada wrote: > After investigation, I found out that my previous patch was wrong > direction. I should have changed XLogSendLogical() so that we can > check the read LSN and set WalSndCaughtUp = true even after read a > record

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

On Wed, Jun 21, 2017 at 11:37 PM, Alex K wrote: >> On 16 Jun 2017, at 21:30, Alexey Kondratov >> wrote: > >> > On 13 Jun 2017, at 01:44, Peter Geoghegan wrote: > > >> > Speculative insertion has the following special entry

Re: pl/perl extension fails on Windows

On Wed, Nov 29, 2017 at 11:34:56PM -0500, Tom Lane wrote: > Noah Misch writes: > > On Thu, Aug 17, 2017 at 12:15:58PM -0400, Tom Lane wrote: > >> ... it's now looking to me like we should do the above with X = 5.13.4. > >> That won't be a perfect solution, but it's about the

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Thu, Nov 30, 2017 at 2:20 PM, Michael Paquier wrote: > This patch does not apply. And the thread has stalled for three months > now but I cannot see a review for what has been submitted. I am moving > it to next CF with waiting on author. Please provide a rebased >

Re: [HACKERS] path toward faster partition pruning

On 2017/11/30 7:15, Robert Haas wrote: > On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas wrote: >> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote >> wrote: >>> It seems I wrote an Assert in the code to support hash partitioning that >>> wasn't

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

On Tue, Aug 22, 2017 at 9:17 PM, Sokolov Yura wrote: > Simplified a bit and more commented patch version is in attach. > > Algorithm were switched to linear probing, it makes code simpler and > clearer. > Flag usages were toggled: now it indicates that hash table were

Re: [HACKERS] <> join selectivity estimate question

Ashutosh Bapat writes: > On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro > wrote: >> Please find attached a new version, and a test script I used, which >> shows a bunch of interesting cases. I'll add this to the commitfest. > I

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On Tue, Nov 28, 2017 at 6:41 AM, Alexander Korotkov wrote: > On Mon, Nov 27, 2017 at 10:56 PM, Robert Haas wrote: >> >> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov >> wrote: >> > pg_prune_xid makes sense only

Re: [HACKERS] Runtime Partition Pruning

Hello, On Wed, Nov 29, 2017 at 7:11 AM, Michael Paquier wrote: > On Wed, Nov 15, 2017 at 3:53 PM, Beena Emerson > wrote: >> Thank you for your suggestion. I am looking into this and will post a >> patch soon. > > It has been two weeks since

Re: Commit fest 2017-11

On 2017/11/30 14:29, Tsunakawa, Takayuki wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >> All patches not marked as ready for committer have been classified, by either >> being marked as returned with feedback or moved to the next CF. >> I may have made some mistakes of course,

Re: Commit fest 2017-11

On Thu, Nov 30, 2017 at 2:29 PM, Tsunakawa, Takayuki wrote: > Now I tried that, successfully marking it as "waiting on author", but the > patch doesn't move to the next CF when I then change the status as "Move to > next CF." How can I move the patch to next CF?

Re: [HACKERS] Removing LEFT JOINs in more cases

Thanks for looking over this and my apologies for the delay in my response. I've been on leave and out of range of the internet for most of that time. On 23 November 2017 at 02:30, Ashutosh Bapat wrote: > > @@ -597,15 +615,25 @@

RE: Commit fest 2017-11

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > All patches not marked as ready for committer have been classified, by either > being marked as returned with feedback or moved to the next CF. > I may have made some mistakes of course, hence if you feel that the status > of your patch is

Re: [HACKERS] logical decoding of two-phase transactions

On 30 November 2017 at 07:40, Petr Jelinek wrote: > Hi, > > On 24/11/17 07:41, Craig Ringer wrote: > > On 24 November 2017 at 13:44, Nikhil Sontakke > > > > > > How practical is adding a lock class? > > > > Am open to suggestions.

Re: Commit fest 2017-11

Michael, thank you for your hard work! > 30 нояб. 2017 г., в 10:39, Michael Paquier > написал(а): > > On Thu, Nov 30, 2017 at 2:29 PM, Tsunakawa, Takayuki > wrote: >> Now I tried that, successfully marking it as "waiting on author",

Re: Allowing SSL connection of v11 client to v10 server with SCRAM channel binding

On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut wrote: > On 11/22/17 21:08, Michael Paquier wrote: >> Yes, agreed. This patch looks good to me. In fe-auth-scram.c, it would >> be also nice to add a comment to keep in sync the logics in >>

RE: Commit fest 2017-11

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > If you have a patch "waiting on author" that you would like to move to the > next commit fest, just switch its status back temporarily to "needs review", > and then do the move. Yes, that's unnecessary complication but I am not > going to

Re: Commit fest 2017-11

On Thu, Nov 30, 2017 at 2:53 PM, Andrey Borodin wrote: > I want to move also "Covering B-tree indexes (aka INCLUDE)" . Seems like we > have common view with Peter Geoghegan and Anastasia that found drawback will > be fixed before next CF. > > If there is no objections,

Would a BGW need shmem_access or database_connection to enumerate databases?

I'm thinking of writing a background worker that will enumerate the databases present, and spin off, for each one, another BGW that will establish a connection and do stuff. For the "master" one, what capabilities will it need to simply enumerate the current names of known databases? I suppose I

Re: Would a BGW need shmem_access or database_connection to enumerate databases?

On Thu, Nov 30, 2017 at 7:48 AM, Chapman Flack wrote: > For the "master" one, what capabilities will it need to simply > enumerate the current names of known databases? I suppose I could > have it connect to the null dbname and query pg_database. Would > that be the

Re: Would a BGW need shmem_access or database_connection to enumerate databases?

On 11/29/2017 05:54 PM, Michael Paquier wrote: > Yes. That's actually what the autovacuum launcher does. It connects > using InitPostgres(NULL, InvalidOid, NULL, NULL), and then scans > pg_database to fetch a list (see get_database_list). Thanks! It looks like if get_database_list were not

  1   2   >