Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Pavan Deolasee
On Fri, Sep 29, 2017 at 1:03 AM, Fabien COELHO wrote: > > The commit that introduced this code is 12788ae49e1933f463bc. So I amn >>> copying Heikki. >>> >> >> AFAICR the commit was mostly a heavy restructuring of previous >> unmaintainable spaghetti code. I'm not sure the

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Pavan Deolasee
On Fri, Sep 29, 2017 at 12:22 AM, Fabien COELHO wrote: > > While running some tests, I encountered a situation where pgbench gets >> stuck in an infinite loop, consuming 100% cpu. The setup was: >> >> - Start postgres server from the master branch >> - Initialise pgbench >>

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

2017-09-28 Thread Kyotaro HORIGUCHI
Hi, At Tue, 19 Sep 2017 17:07:10 +0200, Pierre Ducroquet wrote in <1678633.OBaBNztJnJ@pierred-pdoc> > On Tuesday, September 19, 2017 12:52:37 PM CEST you wrote: > > On Thu, Sep 14, 2017 at 2:17 AM, Pierre Ducroquet > wrote: > > > All my

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

2017-09-28 Thread Vaishnavi Prabakaran
Hi, On Sat, Sep 9, 2017 at 1:29 PM, Haribabu Kommi wrote: > > Fixed patch is attached. > Patch applies and has lot of noise due to indent with spaces. I did ran regression tests located in - src/test/regress, src/test/modules/test_pg_dump, src/bin/pg_dump,

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Andres Freund
On 2017-09-28 20:56:57 -0700, Andres Freund wrote: > +1, I saw the same in a bleeding edge c++ version. err, gcc version. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Andres Freund
On 2017-09-28 20:01:37 -0400, Tom Lane wrote: > I wondered how pervasive this behavior is. AFAICS it is *not* required > by the C standard; C99 does not say that the left operand of assignment > must be evaluated first, in fact it says that the order of evaluation is > unspecified. FWIW, it's

Re: [HACKERS] A design for amcheck heapam verification

2017-09-28 Thread Thomas Munro
On Fri, Sep 29, 2017 at 4:17 PM, Michael Paquier wrote: >> As for DSM, I think that that can come later, and can be written by >> somebody closer to that problem. There can be more than one >> initialization function. > > I don't completely disagree with that, there

Re: [HACKERS] A design for amcheck heapam verification

2017-09-28 Thread Michael Paquier
On Thu, Sep 28, 2017 at 3:32 AM, Peter Geoghegan wrote: > On Wed, Sep 27, 2017 at 1:45 AM, Michael Paquier > wrote: >> I have signed up as a reviewer of this patch, and I have looked at the >> bloom filter implementation for now. This is the kind of

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

2017-09-28 Thread Bossart, Nathan
On 9/28/17, 8:46 PM, "Michael Paquier" wrote: > On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane wrote: >> Michael Paquier writes: >>> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan >>> wrote:

Re: [HACKERS] pg_prepared_xact_status

2017-09-28 Thread Michael Paquier
On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik wrote: > In Postgres 10 we have txid_status function which returns status of > transaction by XID. > I wonder if it will be also useful to have similar function for 2PC > transactions which can operate with GID? >

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

2017-09-28 Thread Michael Paquier
On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote: >>> Alright, I've added logging for autovacuum in v23. I ended up needing to >>> do a

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

2017-09-28 Thread Tom Lane
Michael Paquier writes: > On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote: >> Alright, I've added logging for autovacuum in v23. I ended up needing to >> do a little restructuring to handle the case when the relation was skipped >> because

Re: [HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Amit Langote
On 2017/09/28 22:19, Maksim Milyutin wrote: > I also noticed ambiguity in printing "No partition constraint" in > non-verbose mode and "Partition constraint:..." in verbose one for > partition tables regardless of the type of partition. > Attached small patch removes any output about partition

Re: [HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Amit Langote
On 2017/09/28 22:29, Jesper Pedersen wrote: > On 09/28/2017 09:19 AM, Maksim Milyutin wrote: >>> E.g. "No partition constraint" vs. "Partition constraint: >>> satisfies_hash_partition(...)". >> >> I also noticed ambiguity in printing "No partition constraint" in >> non-verbose mode and "Partition

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

2017-09-28 Thread Michael Paquier
On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan wrote: > Alright, I've added logging for autovacuum in v23. I ended up needing to > do a little restructuring to handle the case when the relation was skipped > because the lock could not be obtained. While doing so, I became

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Tom Lane
Andres Freund writes: > On 2017-09-28 18:39:03 -0400, Tom Lane wrote: >> + * Note: the reason for using a temporary variable "d", here >> and in >> + * other places, is that some compilers think "*op->resvalue = >> f();" >> + * requires

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread Tom Lane
Andres Freund writes: > On 2017-09-28 18:52:28 -0400, Tom Lane wrote: >> Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path >> anymore after this change. > Indeed. But the size of the the oid -> fmgr_builtins index array is > relevant now. We could of

Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)

2017-09-28 Thread Alexander Korotkov
On Thu, Sep 28, 2017 at 2:22 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai > wrote: > >> I am attaching a patch for predicate locking in SP-Gist index >> > > I took a look over this patch. > > newLeafBuffer =

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread Andres Freund
On 2017-09-28 18:52:28 -0400, Tom Lane wrote: > Andres Freund writes: > > I might be worse than you... But anyway, here's a patch doing > > so. Looking at profiles, it turned out that having the integer limits as > > extern variables in a different TU isn't a great idea. > >

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread Tom Lane
Andres Freund writes: > I might be worse than you... But anyway, here's a patch doing > so. Looking at profiles, it turned out that having the integer limits as > extern variables in a different TU isn't a great idea. Uh, what? Access to fmgr_nbuiltins shouldn't be part of

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Andres Freund
On 2017-09-28 18:39:03 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-28 16:21:34 -0400, Tom Lane wrote: > >> We could save a pointless register spill > >> and reload if there were a temporary variable in there, > > > Makes sense. Do you want to make it so, or

Re: [HACKERS] The case for removing replacement selection sort

2017-09-28 Thread Peter Geoghegan
On Thu, Sep 28, 2017 at 3:18 PM, Robert Haas wrote: > On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote: >> With the additional enhancements made to Postgres 10, I doubt that >> there are any remaining cases where it wins. > > I tried my favorite sorting

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Tom Lane
Andres Freund writes: > On 2017-09-28 16:21:34 -0400, Tom Lane wrote: >> We could save a pointless register spill >> and reload if there were a temporary variable in there, > Makes sense. Do you want to make it so, or shall I? I just finished testing a patch, as attached.

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Peter Geoghegan
On Thu, Sep 28, 2017 at 3:20 PM, Robert Haas wrote: > On Thu, Sep 28, 2017 at 5:47 PM, Peter Geoghegan wrote: >> In the end, commit 6bfa88a fixed that old recovery bug by making sure >> the recovery routine heap_xlog_lock() did the right thing. In both >>

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Robert Haas
On Thu, Sep 28, 2017 at 5:47 PM, Peter Geoghegan wrote: > In the end, commit 6bfa88a fixed that old recovery bug by making sure > the recovery routine heap_xlog_lock() did the right thing. In both > cases (Feb 2014 and today), the index wasn't really corrupt -- it just > pointed to

Re: [HACKERS] The case for removing replacement selection sort

2017-09-28 Thread Robert Haas
On Fri, Jul 14, 2017 at 6:20 PM, Peter Geoghegan wrote: > With the additional enhancements made to Postgres 10, I doubt that > there are any remaining cases where it wins. I tried my favorite sorting test case -- pgbench -i -s 300 and then reindex index pgbench_accounts_pkey. I

Re: [HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Andres Freund
Hi, On 2017-09-28 16:21:34 -0400, Tom Lane wrote: > I noticed the following while poking around with perf: > >| fcinfo->isnull = false; >|b5b: movb $0x0,0x1c(%rdx) >| *op->resvalue = > op->d.func.fn_addr(fcinfo);

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Peter Geoghegan
On Thu, Sep 28, 2017 at 2:47 PM, Peter Geoghegan wrote: > In the end, commit 6bfa88a fixed that old recovery bug by making sure > the recovery routine heap_xlog_lock() did the right thing. In both > cases (Feb 2014 and today), the index wasn't really corrupt -- it just > pointed to

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread Andres Freund
On 2017-09-27 15:50:05 -0400, Tom Lane wrote: > ISTM it shouldn't be that hard to get Gen_fmgrtab.pl to emit an index > array of the sort we're talking about, along with the FmgrBuiltin array > it already prints out. I'm the world's worst Perl programmer but > I'm happy to take a stab at it if

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Peter Geoghegan
On Thu, Sep 28, 2017 at 2:39 PM, Alvaro Herrera wrote: >> FWIW, I am reminded a little bit of the MultiXact/recovery bug I >> reported way back in February of 2014 [1], which also had a HOT >> interaction that caused index scans to give wrong answers, despite >> more or

Re: [HACKERS] Arrays of domains

2017-09-28 Thread Tom Lane
Andrew Dunstan writes: > On 09/28/2017 01:11 PM, Tom Lane wrote: >>> I wonder if we need to do any benchmarking to assure ourselves that the >>> changes to ArrayCoerceExpr don't have a significant performance impact? >> That would likely be a good idea, though I'm

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Alvaro Herrera
Peter Geoghegan wrote: > We certainly do still see wrong answers to queries here: > > postgres=# select ctid, xmin, xmax, * from t; > ctid | xmin | xmax | id | name | x > ---+---+--++--+--- > (0,1) | 21171 |0 | 1 | 111 | 0 > (0,7) | 21177 |0 | 3 | 333 | 5 >

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

2017-09-28 Thread Alexander Korotkov
On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote: > On 2017-09-29 00:43:18,"Alexander Korotkov" > wrote: > > On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote: > >> On 2017-09-28 01:29:29,"Alexander Korotkov"

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Peter Geoghegan
On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> Odd that it's not fixed. I guess there's still some more work to do >> here ... > > Maybe what this means is that we need to do both Dan's initially > proposed patch (or something related

Re: [HACKERS] Surjective functional indexes

2017-09-28 Thread Konstantin Knizhnik
On 09/28/2017 10:10 PM, Robert Haas wrote: On Wed, Sep 13, 2017 at 7:00 AM, Simon Riggs wrote: If we do have an option it won't be using fancy mathematical terminology at all, it would be described in terms of its function, e.g. recheck_on_update +1. I have nothing

Re: [HACKERS] Surjective functional indexes

2017-09-28 Thread Oleg Bartunov
On Thu, May 25, 2017 at 7:30 PM, Konstantin Knizhnik wrote: > Right now Postgres determines whether update operation touch index or not > based only on set of the affected columns. > But in case of functional indexes such policy quite frequently leads to > unnecessary

[HACKERS] plpgsql_check future

2017-09-28 Thread Pavel Stehule
Hi The plpgsql_check is mature project now, and I am would to start discussion about future of this project. It is still private project, although it is important for one from key PostgreSQL feature - PLpgSQL. I would be happy if the community can take some responsibility for this project. This

[HACKERS] Minor codegen silliness in ExecInterpExpr()

2017-09-28 Thread Tom Lane
I noticed the following while poking around with perf: | fcinfo->isnull = false; |b5b: movb $0x0,0x1c(%rdx) | *op->resvalue = op->d.func.fn_addr(fcinfo); 0.02 | mov0x8(%rbx),%rcx 1.19 | mov

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Alvaro Herrera
Alvaro Herrera wrote: > Odd that it's not fixed. I guess there's still some more work to do > here ... Maybe what this means is that we need to do both Dan's initially proposed patch (or something related to it) apart from the fixes already pushed. IOW we need to put back some of the "tupkeep"

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-09-28 Thread Alvaro Herrera
Peter Geoghegan wrote: > On Thu, Sep 28, 2017 at 7:47 AM, Alvaro Herrera > wrote: > > Fix freezing of a dead HOT-updated tuple > > If I run Dan Wood's test case again, the obvious symptom (spurious > duplicates) goes away. However, the enhanced amcheck, and thus CREATE

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

2017-09-28 Thread chenhj
On 2017-09-29 00:43:18,"Alexander Korotkov" wrote: On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote: On 2017-09-28 01:29:29,"Alexander Korotkov" wrote: It appears that your patch conflicts with fc49e24f. Please, rebase it.

[HACKERS] initdb w/ restart

2017-09-28 Thread Jesper Pedersen
Hi, In a case of initdb /tmp/pgsql followed by pg_ctl -D /tmp/pgsql/ -l /tmp/logfile restart you'll get pg_ctl: PID file "/tmp/pgsql/postmaster.pid" does not exist Is server running? starting server anyway pg_ctl: could not read file "/tmp/pgsql/postmaster.opts" The attached patch changes

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Fabien COELHO
The commit that introduced this code is 12788ae49e1933f463bc. So I amn copying Heikki. AFAICR the commit was mostly a heavy restructuring of previous unmaintainable spaghetti code. I'm not sure the problem was not there before under one form or another. I agree that it should error out &

Re: [HACKERS] Surjective functional indexes

2017-09-28 Thread Robert Haas
On Wed, Sep 13, 2017 at 7:00 AM, Simon Riggs wrote: > If we do have an option it won't be using fancy mathematical > terminology at all, it would be described in terms of its function, > e.g. recheck_on_update +1. > Yes, I'd rather not have an option at all, just some

Re: [HACKERS] Domains and arrays and composites, oh my

2017-09-28 Thread Tom Lane
Andrew Dunstan writes: > On 09/28/2017 01:02 PM, Tom Lane wrote: >>> I do think that treating a function returning a domain-over-composite >>> differently from one returning a base composite is a POLA. We'd be very >>> hard put to explain the reasons for it to an

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread Tom Lane
I wrote: > [ we should use an index array ] Just to prove the point, I threw together the attached trivial test case, which time-trials the existing fmgr_isbuiltin implementation against both the proposed hash implementation and a simple index array. On my machine, with a repeat count of 1,

Re: [HACKERS] Domains and arrays and composites, oh my

2017-09-28 Thread Andrew Dunstan
On 09/28/2017 01:02 PM, Tom Lane wrote: > >> I do think that treating a function returning a domain-over-composite >> differently from one returning a base composite is a POLA. We'd be very >> hard put to explain the reasons for it to an end user. > Do you have any thoughts about how we ought to

Re: [HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Fabien COELHO
While running some tests, I encountered a situation where pgbench gets stuck in an infinite loop, consuming 100% cpu. The setup was: - Start postgres server from the master branch - Initialise pgbench - Run pgbench -c 10 -T 100 - Stop postgres with -m immediate That is a strange test to run,

Re: [HACKERS] Arrays of domains

2017-09-28 Thread Andrew Dunstan
On 09/28/2017 01:11 PM, Tom Lane wrote: > >> I wonder if we need to do any benchmarking to assure ourselves that the >> changes to ArrayCoerceExpr don't have a significant performance impact? > That would likely be a good idea, though I'm not very sure what or > how to benchmark. > >

Re: [HACKERS] 200 = 199 + 1?

2017-09-28 Thread Tom Lane
Marko Tiikkaja writes: > On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote: >> Looking at it another way, the main thing that the combination of hashagg >> outer path + indexscan inner path knows that eqjoinsel_semi didn't account >> for is that there's a unique

Re: [HACKERS] Arrays of domains

2017-09-28 Thread Tom Lane
Andrew Dunstan writes: > On 08/11/2017 01:17 PM, Tom Lane wrote: >> Attached is a patch series that allows us to create arrays of domain >> types. > I've reviewed and tested the updated versions of these patches. The > patches apply but there's an apparent typo in

Re: [HACKERS] Domains and arrays and composites, oh my

2017-09-28 Thread Tom Lane
Andrew Dunstan writes: > On 07/13/2017 03:19 PM, Tom Lane wrote: >> Attached is a draft patch that allows domains over composite types. >> I think it's probably complete on its own terms, but there are some >> questions around behavior of functions returning

[HACKERS] pg_prepared_xact_status

2017-09-28 Thread Konstantin Knizhnik
Hi, In Postgres 10 we have txid_status function which returns status of transaction by XID. I wonder if it will be also useful to have similar function for 2PC transactions which can operate with GID? pg_prepared_xacts view allows to get information about prepared transaction which are not

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

2017-09-28 Thread Alexander Korotkov
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote: > On 2017-09-28 01:29:29,"Alexander Korotkov" > wrote: > > It appears that your patch conflicts with fc49e24f. Please, rebase it. > > > Yes, i had rebased it, Please check the new patch. > Good, now it

Re: [HACKERS] crash-recovery test vs windows

2017-09-28 Thread Andrew Dunstan
On 09/28/2017 12:29 PM, Andrew Dunstan wrote: > The new crash-recovery check is failing pretty reliably on jacana. It's > already excluded on MSVC machines, so I'm inclined to exclude it on Msys > as well. > > Sorry, I meant crash-restart cheers andrew -- Andrew Dunstan

[HACKERS] crash-recovery test vs windows

2017-09-28 Thread Andrew Dunstan
The new crash-recovery check is failing pretty reliably on jacana. It's already excluded on MSVC machines, so I'm inclined to exclude it on Msys as well. Thoughts? cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

2017-09-28 Thread chenhj
On 2017-09-28 01:29:29,"Alexander Korotkov" wrote: It appears that your patch conflicts with fc49e24f. Please, rebase it. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company Yes, i had rebased it, Please

Re: [HACKERS] Domains and arrays and composites, oh my

2017-09-28 Thread Andrew Dunstan
On 07/13/2017 03:19 PM, Tom Lane wrote: > I wrote: >> I started to look into allowing domains over composite types, which is >> another never-implemented case that there's no very good reason not to >> allow. Well, other than the argument that the SQL standard only allows >> domains over

Re: [HACKERS] PoC: full merge join on comparison clause

2017-09-28 Thread Alexander Kuzmenkov
Hi Ashutosh, Thanks for the review. *Jeff*, I'm copying you because this is relevant to our discussion about what to do with mergeopfamilies when adding new merge join types. You have renamed RestrictInfo member mergeopfamilies as equivopfamilies. I don't think that's a good name; it

Re: [HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Maksim Milyutin
On 28.09.2017 16:29, Jesper Pedersen wrote: On 09/28/2017 09:19 AM, Maksim Milyutin wrote: E.g. "No partition constraint" vs. "Partition constraint: satisfies_hash_partition(...)". I also noticed ambiguity in printing "No partition constraint" in non-verbose mode and "Partition

Re: [HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Jesper Pedersen
On 09/28/2017 09:19 AM, Maksim Milyutin wrote: E.g. "No partition constraint" vs. "Partition constraint: satisfies_hash_partition(...)". I also noticed ambiguity in printing "No partition constraint" in non-verbose mode and "Partition constraint:..." in verbose one for partition tables

Re: [HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Maksim Milyutin
Hi! On 28.09.2017 16:02, Jesper Pedersen wrote: Hi, Using hash partitions I noticed that \d gives D=# \d T_p63    Table "public.T_p63"     Column | Type  | Collation | Nullable | Default ---+---+---+--+- Partition of:

[HACKERS] Partitions: \d vs \d+

2017-09-28 Thread Jesper Pedersen
Hi, Using hash partitions I noticed that \d gives D=# \d T_p63 Table "public.T_p63" Column | Type | Collation | Nullable | Default ---+---+---+--+- Partition of: T FOR VALUES WITH (modulus 64, remainder 63) No

Re: [HACKERS] Optional message to user when terminating/cancelling backend

2017-09-28 Thread Yugo Nagata
On Sun, 3 Sep 2017 22:47:10 +0200 Daniel Gustafsson wrote: I have reviewed your latest patch. I can apply this to the master branch and build this successfully, and the behavior is as expected. However, here are some comments and suggestions. > 135 + char

[HACKERS] pgbench stuck with 100% cpu usage

2017-09-28 Thread Pavan Deolasee
Hello, While running some tests, I encountered a situation where pgbench gets stuck in an infinite loop, consuming 100% cpu. The setup was: - Start postgres server from the master branch - Initialise pgbench - Run pgbench -c 10 -T 100 - Stop postgres with -m immediate Now it seems that pgbench

[HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

2017-09-28 Thread Etsuro Fujita
Hi, Commit 7086be6e3627c1ad797e32ebbdd232905b5f577f addressed mishandling of WCO in direct foreign table modification by disabling it when we have WCO, but I noticed another oddity in postgres_fdw: postgres=# create table base_tbl (a int, b int); postgres=# create function

Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)

2017-09-28 Thread Alexander Korotkov
Hi! On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai wrote: > I am attaching a patch for predicate locking in SP-Gist index > I took a look over this patch. newLeafBuffer = SpGistGetBuffer(index, > GBUF_LEAF | (isNulls ? GBUF_NULLS : 0), > Min(totalLeafSizes, >

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

2017-09-28 Thread Alexander Korotkov
Hi! On Wed, Jun 21, 2017 at 10:52 AM, Shubham Barai wrote: > Hi, > > On 21 June 2017 at 13:11, Heikki Linnakangas wrote: > >> On 06/16/2017 01:24 PM, Shubham Barai wrote: >> >>> @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, >>>

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

2017-09-28 Thread Alexander Korotkov
On Thu, Sep 28, 2017 at 12:45 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Aug 9, 2017 at 6:30 PM, Shubham Barai > wrote: > >> Please find the updated patch for predicate locking in gin index here. >> >> There was a small issue in the previous

Re: [HACKERS] Parallel Append implementation

2017-09-28 Thread Amit Khandekar
On 20 September 2017 at 11:32, Amit Khandekar wrote: > There is still the open point being > discussed : whether to have non-parallel-aware partial Append path, or > always have parallel-aware Append paths. Attached is the revised patch v16. In previous versions, we used

Re: [HACKERS] [POC] hash partitioning

2017-09-28 Thread amul sul
On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote wrote: > On 2017/09/27 22:41, Jesper Pedersen wrote: >> On 09/27/2017 03:05 AM, amul sul wrote: > Attached rebased patch, thanks. > > While reading through the patch I thought it would be better to keep

Re: [HACKERS] Partition-wise aggregation/grouping

2017-09-28 Thread Ashutosh Bapat
On Wed, Sep 27, 2017 at 3:42 PM, Jeevan Chalke wrote: > Thanks Ashutosh for reviewing. > > Attached new patch-set with following changes: > > 1. Removed earlier 0007 and 0008 patches which were PoC for supporting > partial aggregation over fdw. I removed them as it

Re: [HACKERS] path toward faster partition pruning

2017-09-28 Thread David Rowley
On 27 September 2017 at 14:22, Amit Langote wrote: > - 0001 includes refactoring that Dilip proposed upthread [1] (added him as > an author). I slightly tweaked his patch -- renamed the function > get_matching_clause to match_clauses_to_partkey, similar to >

Re: [HACKERS] path toward faster partition pruning

2017-09-28 Thread Dilip Kumar
On Thu, Sep 28, 2017 at 1:44 PM, Amit Langote wrote: > On 2017/09/28 13:58, Dilip Kumar wrote: >> I think the above logic is common between this patch and the runtime >> pruning. I think we can make >> a reusable function. Here we are preparing minkey and maxkey

Re: [HACKERS] path toward faster partition pruning

2017-09-28 Thread Amit Langote
On 2017/09/28 13:58, Dilip Kumar wrote: > On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote > wrote: > > I was looking into the latest patch set, seems like we can reuse some > more code between this path and runtime pruning[1] > > + foreach(lc1, matchedclauses[i]) >

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

2017-09-28 Thread Amit Langote
On 2017/09/28 16:13, Ashutosh Bapat wrote: > On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote: >> On 2017/09/21 12:42, Robert Haas wrote: >>> Associate partitioning information with each RelOptInfo. >>> >>> This is not used for anything yet, but it is necessary infrastructure >>> for

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

2017-09-28 Thread Ashutosh Bapat
On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote: > On 2017/09/21 12:42, Robert Haas wrote: >> Associate partitioning information with each RelOptInfo. >> >> This is not used for anything yet, but it is necessary infrastructure >> for partition-wise join and for

Re: [HACKERS] UPDATE of partition key

2017-09-28 Thread Amit Khandekar
Below are some performance figures. Overall, there does not appear to be a noticeable difference in the figures in partition key updates with and without row movement (which is surprising), and non-partition-key updates with and without the patch. All the values are in milliseconds.

Re: [HACKERS] Use of RangeVar for partitioned tables in autovacuum

2017-09-28 Thread Amit Langote
Thanks Michael for working on this. On 2017/09/27 11:28, Michael Paquier wrote: > Hi all, > > I have been looking more closely at the problem in $subject, that I > have mentioned a couple of times, like here: >

Re: [HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

2017-09-28 Thread Amit Langote
Sorry, I meant to say PartitionSchem"e"Data in subject. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PartitionSchemaData & partcollation (Re: [COMMITTERS] pgsql: Associate partitioning information with each RelOptInfo.)

2017-09-28 Thread Amit Langote
On 2017/09/21 12:42, Robert Haas wrote: > Associate partitioning information with each RelOptInfo. > > This is not used for anything yet, but it is necessary infrastructure > for partition-wise join and for partition pruning without constraint > exclusion. > > Ashutosh Bapat, reviewed by Amit

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

2017-09-28 Thread tushar
On 09/27/2017 05:29 PM, tushar wrote: After discussion with Jeevan Ladhe, we created a sql query which contain lots of inbuild function and tested that against pgbench    with master v/s patch and found an improvement I tested it again and found around +2% improvement ./pgbench -c 8 -j 8 -f

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-09-28 Thread Pavel Stehule
Hi now xpath and xpath_exists supports default namespace too updated doc, fixed all variants of expected result test file Regards Pavel diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 2f036015cc..610f709933 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@