Re: [HACKERS] Proposal for changes to recovery.conf API

: > \"%s\"", *newval); > + return false; > + } > + > + myextra = (RecoveryTargetAction *) guc_malloc(ERROR, > sizeof(RecoveryTargetAction)); > + *myextra = rta; > + *extra = (void *) myextra; > + > + return true; > +} Should be an enum. > +stat

Re: [HACKERS] Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.

On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > Andres Freund writes: > > Committed after simplifying the Makefile. > > While I have no particular objection to adding these tests, the > commit log's claim that this will improve buildfarm testing is > quite wrong.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.

On 2016-11-12 11:42:12 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > >> which is a rather blatant waste of cycles. I would suggest an explicit > >> do-nothing installcheck rule rather than the hack you came up with

Re: [HACKERS] Indirect indexes

Hi, On 2016-11-01 01:43:31 -0300, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > I propose we introduce the concept of "indirect indexes". > > This is a WIP non-functional patch for indirect indexes. I've been > distracted from working on it for some time already and will be off-line > for ha

Re: [HACKERS] Logical Replication WIP

On 2016-11-10 23:31:27 +0100, Petr Jelinek wrote: > On 04/11/16 13:15, Andres Freund wrote: > > > > /* Prototypes for private functions */ > > -static bool libpq_select(int timeout_ms); > > +static bool libpq_select(PGconn *streamConn, > > +

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, Subject: [PATCH 1/2] slab allocator diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c index 6ad7e7d..520f295 100644 --- a/src/backend/replication/logical/reorderbuffer.c +++ b/src/backend/replication/logical/reorderbuffer.c I'd ra

Re: [HACKERS] Logical Replication WIP

Hi, On 2016-11-11 12:04:27 +0100, Petr Jelinek wrote: > On 04/11/16 14:00, Andres Freund wrote: > > Hi, > > > > + > > + pg_publication_rel > > + > > + > > + pg_publication_rel > > + > > + > > + > > + The p

Re: [HACKERS] pg_dump, pg_dumpall and data durability

Hi, On 2016-11-08 18:18:01 -0500, Tom Lane wrote: > I think this might be better addressed by adding something to backup.sgml > pointing out that you'd better fsync or sync your backups before assuming > that they can't be lost. How does a normal user do that? I don't think there's a cross-platfo

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 2016-11-13 00:20:22 -0500, Peter Eisentraut wrote: > On 11/11/16 11:10 AM, Tom Lane wrote: > > boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool > > boolin: prosrc=boolin provolatile=i proparallel=s > > Then we're not very far away from just using CREATE FUNCTION SQL command

Re: [HACKERS] Logical Replication WIP

On 2016-11-13 00:40:12 -0500, Peter Eisentraut wrote: > On 11/12/16 2:18 PM, Andres Freund wrote: > >>> I also wonder if we want an easier to > >>> > > extend form of pubinsert/update/delete (say to add pubddl, > >>> > > pubtrun

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

ood number of things rely on the builtin type oids being essentially stable. > > If we can generalize this to other catalogs, then that will be good, but > > my inclination is to handle the elephant in the room (pg_proc.h) and > > worry about the gnats later. > > I thin

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 2016-11-13 11:23:09 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-13 00:20:22 -0500, Peter Eisentraut wrote: > >> Then we're not very far away from just using CREATE FUNCTION SQL commands. > > > Well, those do a lot of syscache looku

[HACKERS] ExplainOneQuery_hook ignored for EXPLAIN EXECUTE

not entirely trivial to fix, because the hook accepts a Query, not a PlannedStmt. Does anybody have a good way to fix this? Greetings, Andres Freund -- 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] ExplainOneQuery_hook ignored for EXPLAIN EXECUTE

On 2016-11-13 17:20:05 -0500, Tom Lane wrote: > Andres Freund writes: > > I don't quite know what the hook in $subject was originally designed > > for, but right now it has the problem that it's not invoked for EXPLAIN > > EXECUTE. That's becaus

Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary

On 2016-11-14 10:09:02 -0500, Robert Haas wrote: > On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund wrote: > > On 2016-08-30 07:38:10 -0400, Tom Lane wrote: > >> Heikki Linnakangas writes: > >> > While profiling some queries and looking at executor overhead, I

Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary

On 2016-11-14 12:32:53 -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > On 11/14/2016 06:18 PM, Tom Lane wrote: > >> You're implicitly assuming that a scan always returns its results in the > >> same slot, and that no other slot could contain a copy of that data, but > >> there is no guaran

Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary

On 2016-11-14 13:12:28 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-14 12:32:53 -0500, Tom Lane wrote: > >> Basically my concern is that this restriction isn't documented anywhere > >> and I'm not entirely certain it's been adhered to ev

Re: [HACKERS] Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.

On 2016-11-12 11:42:12 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > >> which is a rather blatant waste of cycles. I would suggest an explicit > >> do-nothing installcheck rule rather than the hack you came up with

Re: [HACKERS] Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.

On 2016-11-14 12:14:10 -0800, Andres Freund wrote: > On 2016-11-12 11:42:12 -0500, Tom Lane wrote: > > Andres Freund writes: > > > On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > > >> which is a rather blatant waste of cycles. I would suggest an explicit > > &g

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

rt found. I'm still playing around with it, but basically the fix is to make the growth policy a bit more adaptive. Greetings, Andres Freund -- 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] amcheck (B-Tree integrity checking tool)

Hi, I think the patch could use a pgindent run. On 2016-09-07 11:44:01 -0700, Peter Geoghegan wrote: > diff --git a/contrib/amcheck/amcheck--1.0.sql > b/contrib/amcheck/amcheck--1.0.sql > new file mode 100644 > index 000..ebbd6ac > --- /dev/null > +++ b/contrib/amcheck/amcheck--1.0.sql > @@

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

Hi, On 2016-11-16 19:29:41 -0500, Robert Haas wrote: > On Wed, Nov 16, 2016 at 6:56 PM, Michael Paquier > wrote: > > On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas wrote: > >> diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile > >> index 805db76..ddb0183 100644 > >> --- a/contrib/

Re: [HACKERS] Mail thread references in commits

On November 17, 2016 1:02:38 PM PST, Andrew Dunstan wrote: >I love seeing references to email threads in commit messages. It would >make them a lot friendlier though if a full http URL were included >instead of just a Message-ID, i.e. instead of put >

Re: [HACKERS] WAL recycle retading based on active sync rep.

for a chackepoint period. I very strongly think not. > - Is the measure acceptable? For the worst case, a master > crashes from WAL space exhaustion. (But such large transaction > won't/shouldn't exist?) No, imo not. Greetings, Andres Freund -- Sent via pgsql-hacker

Re: [HACKERS] Mail thread references in commits

On November 18, 2016 1:06:18 PM PST, Tom Lane wrote: >Robert Haas writes: >> On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake >wrote: >>> Why not hash the URL? Something like: >>> Http://postgresopen.org/archive/743257890976432 > >> I suggested that upthread... > >Don't like the hashing idea bec

Re: [HACKERS] Logical decoding on standby

Hi, On 2016-11-21 16:17:58 +0800, Craig Ringer wrote: > I've prepared a working initial, somewhat raw implementation for > logical decoding on physical standbys. Please attach. Otherwise in a year or two it'll be impossible to look this up. Andres -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On February 17, 2017 11:40:57 AM PST, Tom Lane wrote: >I wrote: >> Yeah. I have longfin which is running Apple's clang, and is on a >machine >> that doesn't have much to do otherwise. I propose to turn on -Werror >in >> its configuration, and to configure a second critter on the same >hardware

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

On February 17, 2017 1:13:10 PM PST, Mark Dilger wrote: >How about we add (some of) these extra warnings, plus -Werror, >in a section that is only active for platforms/compilers where we >know there aren't spurious warnings? That would make detecting >unintentionally introduced warnings simple

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-19 10:49:29 -0500, Tom Lane wrote: > Robert Haas writes: > > On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote: > >> Thoughts? Should we double down on trying to make this work according > >> to the "all integer timestamps" protocol specs, or cut our losses and > >> change the specs? >

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: > That being said, I did wonder myself if we should just deprecate float > timestamps as well. I think we need a proper deprecation period for that, given that the conversion away will be painful for pg_upgrade using people with big clusters. So I

Re: [HACKERS] How to read a value when it is VARATT EXTERNAL ONDISK from logical replication decoder

Hi, On 2017-02-20 11:44:58 +0100, Adam Dratwiński wrote: > Hello everyone, > > I am writing a custom logical replication decoder, and I took test decoder > from Postgres sources as an example. > > Could anyone tell me how to read "unchanged toast datum" in case it is > VARTT_IS_EXTERNAL_ONDISK.

[HACKERS] "may be unused" warnings for gcc

retty hard to figure out that rawdata has to be set at that point. Greetings, Andres Freund -- 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] Should we cacheline align PGXACT?

Hi, On 2017-02-21 16:57:36 +0530, Ashutosh Sharma wrote: > Yes, there is still some regression however it has come down by a > small margin. I am not doing initdb for each run instead I am doing, > dropdb-->createdb-->pgbench -i. Is dropping old database and creating > a new one for every run not

Re: [HACKERS] "may be unused" warnings for gcc

On 2017-02-21 17:20:44 -0500, Peter Eisentraut wrote: > On 2/20/17 09:41, Andres Freund wrote: > > When building with a new-ish gcc (6.3.0 right now, but I've seen this > > for a while) with optimization I get a number of warnings: > > These all look like related to

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-22 00:10:35 -0600, Jim Nasby wrote: > On 2/20/17 5:04 AM, Andres Freund wrote: > > On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: > > > That being said, I did wonder myself if we should just deprecate float > > > timestamps as well. > > > &g

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-22 08:43:28 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-02-22 00:10:35 -0600, Jim Nasby wrote: > >> I wounder if a separate "floatstamp" data type might fit the bill there. It > >> might not be completely seamless, but it would be bin

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-22 09:06:38 -0600, Jim Nasby wrote: > On 2/22/17 7:56 AM, Andres Freund wrote: > > It sounded more like Jim suggested a full blown SQL type, given that he > > replied to my concern about the possible need for a deprecation period > > due to pg_upgrade concerns.

Re: [HACKERS] Make subquery alias optional in FROM clause

On 2017-02-23 08:21:41 +0530, Robert Haas wrote: > On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote: > > On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote: > >> Bernd Helmle writes: > >> >> From time to time, especially during migration projects from Oracle to > >> > PostgreSQL, i'm f

Re: [HACKERS] A typo in mcxt.c

On 2017-02-23 14:26:07 -0600, Jim Nasby wrote: > On 2/23/17 6:38 AM, Thomas Munro wrote: > > > I'm not so confident, but the "'tis" seems to me to be a typo of > > > "it's". > > That is an archaic way of contracting the same words differently: > > Given the number of non-native English speakers we

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-23 17:28:26 -0500, Tom Lane wrote: > Jeff Janes writes: > > The number of new chunks can be almost as as large as the number of old > > chunks, especially if there is a very popular value. The problem is that > > every time an old chunk is freed, the code in aset.c around line 968 has

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-24 01:59:01 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-02-23 17:28:26 -0500, Tom Lane wrote: > >> Maybe it's time to convert that to a doubly-linked list. > > > Yes, I do think so. Given that we only have that for full blocks, not >

Re: [HACKERS] safer node casting

ters, but the new code won't. Which means 9ba8a9ce4548b et al actually weakened some asserts. Should we perhaps have one NULL accepting version (castNodeNull?) and one that separately asserts that ptr != NULL? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] PATCH: two slab-like memory allocators

kinda inclined to drop SlabFreeInfo/SlabAllocInfo. I've not yet looked a lot at the next type of context - I want to get this much committed first... I plan to give this another pass sometime this weekend and then push soon. - Andres >From cec3f8372137d2392ff7ac0ab1b2db11fc96e8b3 Mon

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > Concretely, something like the attached. This passes regression tests > but I've not pushed on it any harder than that. Heh, I'd just gotten something that didn't immediately crash anymore ;) Running your patch against Jeff's test-case, verified be

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-24 15:12:37 -0800, Andres Freund wrote: > On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > > Concretely, something like the attached. This passes regression tests > > but I've not pushed on it any harder than that. > > Heh, I'd just gotten somethin

Re: [HACKERS] PGSERVICEFILE as a connection string parameter

Hi, On 2017-02-27 14:43:49 +0900, Michael Paquier wrote: > I bumped into a case where it would have been rather useful to specify > a service file path in a connection string with a service name. In my > case, I have finished by setting up PGSERVICEFILE, but now like > PGPASSFILE I think that bein

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-24 14:10:38 -0800, Andres Freund wrote: > I've not yet looked a lot at the next type of context - I want to get > this much committed first... > > I plan to give this another pass sometime this weekend and then push > soon. Before committing I wanted to

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-24 15:18:04 -0800, Andres Freund wrote: > On 2017-02-24 15:12:37 -0800, Andres Freund wrote: > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > > > Concretely, something like the attached. This passes regression tests > > > but I've not pushed on it an

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-27 03:17:32 -0800, Andres Freund wrote: > I'll work on getting slab committed first, and then review / edit / > commit generation.c later. One first note there is that I'm wondering > if generation.c is a too generic filename. And pushed slab and its usage.

Re: [HACKERS] PATCH: two slab-like memory allocators

On February 27, 2017 6:14:20 AM PST, Tomas Vondra wrote: >On 02/27/2017 01:02 PM, Andres Freund wrote: >> Hi, >> >> On 2017-02-27 03:17:32 -0800, Andres Freund wrote: >>> I'll work on getting slab committed first, and then review / edit / >>> commit

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-27 10:32:25 -0500, Tom Lane wrote: > Andres Freund writes: > > And pushed slab and its usage. Will have a look at generation.c > > tomorrow. > > Perhaps first you need to find out why so much of the buildfarm > is unhappy. Will do, after a morning coffee.

Re: [HACKERS] PGSERVICEFILE as a connection string parameter

On 2017-02-27 16:23:46 +0100, Magnus Hagander wrote: > On Mon, Feb 27, 2017 at 7:03 AM, Andres Freund wrote: > > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote: > > > I bumped into a case where it would have been rather useful to specify > > > a service file path

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-27 07:55:32 -0800, Andres Freund wrote: > On 2017-02-27 10:32:25 -0500, Tom Lane wrote: > > Andres Freund writes: > > > And pushed slab and its usage. Will have a look at generation.c > > > tomorrow. > > > > Perhaps first you need to find

Re: [HACKERS] PATCH: two slab-like memory allocators

ly triggered a memory context reset when it was empty... But I ran decoding while a concurrent write transaction was ongoing... > > I'll work on getting slab committed first, and then review / edit / > > commit generation.c later. One first note there is that I'm wondering >

Re: [HACKERS] PATCH: two slab-like memory allocators

; (changes to integer timestamps). We should probably look at 32bit machines > first. Don't think so - termite is ppc64 afaics, and the failure doesn't look integer timestamp related (assert failure is clearly about this, and set of changed commits *only* include slab related commits). G

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-27 18:04:41 +0100, Petr Jelinek wrote: > On 27/02/17 18:00, Andres Freund wrote: > > > >> FWIW I think the ppc64 machines are failing because of unrelated issue > >> (changes to integer timestamps). We should probably look at 32bit machines > >> firs

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-27 12:27:48 -0500, Tom Lane wrote: > Andres Freund writes: > > The best theory I have so far that I have is that slab.c's idea of > > StandardChunkHeader's size doesn't match what mcxt.c think it is > > (because slab.c simply embeds StandardChu

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On 2017-02-27 23:09:40 +0530, Robert Haas wrote: > On Mon, Feb 27, 2017 at 9:39 PM, David Steele wrote: > > I'm happy to be CFM. Somehow I doubt there will be a lot of objections! > > No. Aren't you the guy who did a good job with it last year and just > about perished in the process? Yea, I w

Re: [HACKERS] Poor memory context performance in large hash joins

On 2017-02-27 19:20:56 +0100, Tomas Vondra wrote: > On 02/27/2017 12:55 PM, Andres Freund wrote: > > On 2017-02-24 15:18:04 -0800, Andres Freund wrote: > > > On 2017-02-24 15:12:37 -0800, Andres Freund wrote: > > > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote: &

Re: [HACKERS] Replication vs. float timestamps is a disaster

On 2017-02-27 17:00:23 -0800, Joshua D. Drake wrote: > On 02/22/2017 02:45 PM, Tom Lane wrote: > > Andres Freund writes: > > > On 2017-02-22 08:43:28 -0500, Tom Lane wrote: > > > > (To be concrete, I'm suggesting dropping --disable-integer-datetimes > > &

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 01:44:42 +0100, Tomas Vondra wrote: > On 02/27/2017 06:42 PM, Andres Freund wrote: > > Yea, I hadn't yet realized when writing that that termite actually, > > despite running on ppc64, compiles a 32bit postgres. Will thus > > duplicate StandardChunkHead

Re: [HACKERS] PATCH: two slab-like memory allocators

doable enough. Hm, that should be doable with something like #if MAXIMUM_ALIGNOF > 4 && SIZEOF_VOID_P == 4 which'd probably be better documentation than a macro that hides this (arguing internally whether SIZEOF_VOID_P or SIZEOF_SIZE_T) is better. Working on a patch now, will post but

Re: [HACKERS] PATCH: two slab-like memory allocators

attached works on a platform that's currently failing. Thanks! - Andres >From a59c3200dd127feb0cb09a055250ff6401aee1aa Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Mon, 27 Feb 2017 23:32:22 -0800 Subject: [PATCH] Remove StandardChunkHeader for Slab's benefit. --- src/backend/utils/mmg

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-02-26 19:30:32 +0530, Robert Haas wrote: > On Wed, Feb 22, 2017 at 11:23 AM, Kuntal Ghosh > wrote: > > While conducting the experiments for parallelism, Rafia came across a > > hang in Q18 when plan uses partial and finalize hash aggregate. This > > could be seen on both scale factor

Re: [HACKERS] New Committer - Andrew Gierth

Hi, On 2017-02-28 13:22:22 -0500, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a new > committer for the PostgreSQL project. > > Andrew - welcome! Congratulations Andrew! We now have two Andrews and one Andres amongst the committers...

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > *preliminary* patch attached. This needs a good bit of polishing > (primarily comment work, verifying that valgrind works), but I'm too > tired now. > > I'm not quite sure how to deal with mmgr/README - it

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 2017-02-28 15:59:08 +0100, Andreas Karlsson wrote: > On 02/28/2017 03:13 PM, Bruce Momjian wrote: > > I might have added that one; the text is: > > > > Consider disallowing multiple queries in PQexec() > > as an additional barrier to SQL injection attacks > > > > and it is a "consider"

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 08:42:35 +0530, Robert Haas wrote: > On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund wrote: > >> To me, it seems like a big problem that we have large, unfixed > >> performance regressions with simplehash four months after it went in. > > > > Yea, I

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:13:15 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the > >> issue. Ob

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 09:21:47 +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 8:48 AM, Andres Freund wrote: > >> BTW, another option to consider is lowering the target fillfactor. > >> IIRC, Kuntal mentioned to me that cranking it down seemed to fix the > >> issue. Ob

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-03-01 09:33:07 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: > >> So, I was looking for other alternatives and I've found one called > >> RobinHood hashing. > > > > simplehash.h implements robin hood has

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 10:41:22 -0800, Andres Freund wrote: > Hi, > > On 2017-02-27 23:44:20 -0800, Andres Freund wrote: > > *preliminary* patch attached. This needs a good bit of polishing > > (primarily comment work, verifying that valgrind works), but I'm too > > tired

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > - Andres, hoping the buildfarm turns greener Oh well, that didn't work. Investigating. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpr

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: > if (insertdist > curdist) > { > swap the entry to be inserted with the current entry. > Try to insert the current entry in the same logic. > } > > So, the second approach will not cause all the followers to be shifted by 1. How not? You'll have

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi, On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: > On 1/26/17 22:46, Andres Freund wrote: > > On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > >> Yeah, I have committed a few of the patches now and I'll close the CF > >> entry now. Thanks for

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > Hi, > > I'm wondering if it's not time for $subject: > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > forgotten > - They have us keep weird hacks around just for the sake of testing V0 > -

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2017-02-28 23:15:15 -0800, Andres Freund wrote: > On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > > Hi, > > > > I'm wondering if it's not time for $subject: > > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > > forgotten

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2017-02-28 12:42:32 +0900, Michael Paquier wrote: > Please no. Replication slots are designed the current way because we > don't want to have to use something like wal_keep_segments as it is a > wart, and this applies as well for replication slots in my opinion. I think a per-slot option t

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2017-03-01 11:18:34 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-12-08 13:34:41 -0800, Andres Freund wrote: > >> Hi, > >> > >> I'm wondering if it's not time for $subject: > >> - V0 causes confusion / weird crashes when PG_

Re: [HACKERS] Possible spelling fixes

On 2017-03-01 14:40:26 -0300, Alvaro Herrera wrote: > Josh Soref wrote: > > > One thing that would be helpful is if someone could comment on: > > https://github.com/jsoref/postgres/commit/9050882d601134ea1ba26f77ce5f1aaed75418de > > -#undef SH_ITERTOR > > +#undef SH_ITERATOR > > > > It's unclear

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-01 10:20:41 -0800, David Fetter wrote: > On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: > > On 2/28/17 04:24, vinayak wrote: > > > The view provides the information of analyze command progress details as > > > follows > > > postgres=# \d pg_stat_progress_analyze > > >

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-01 10:25:49 -0800, Andres Freund wrote: > We now have a framework for this [1] (currently used by vacuum, but > extensible). The question is about presentation. I'm fairly sure that > we shouldn't just add yet another framework, and I doubt that that's &g

Re: [HACKERS] ANALYZE command progress checker

On March 1, 2017 11:34:48 AM PST, David Fetter wrote: >I notice that that commit has no SGML component. Should it have one? Don't think so. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-02-28 20:29:36 -0800, Andres Freund wrote: > On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > > - Andres, hoping the buildfarm turns greener > > Oh well, that didn't work. Investigating. The fix for that was fairly trivial, and the buildfarm has cooled down. T

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 2017-03-01 19:25:23 -0600, Jim Nasby wrote: > On 2/28/17 11:21 AM, Andreas Karlsson wrote: > > The only downside I can see to this approach is that we no logner will > > able to reindex catalog tables concurrently, but in return it should be > > easier to confirm that this approach can be made w

Re: [HACKERS] PATCH: two slab-like memory allocators

still be somewhat relevant; removed and added it, not sure what's better. Greetings, Andres Freund -- 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] PATCH: two slab-like memory allocators

On 2017-03-02 04:47:13 +0100, Tomas Vondra wrote: > On 03/01/2017 11:55 PM, Andres Freund wrote: > > On 2017-02-28 20:29:36 -0800, Andres Freund wrote: > > > On 2017-02-28 20:18:35 -0800, Andres Freund wrote: > > > > - Andres, hoping the buildfarm turns greener >

Re: [HACKERS] Performance degradation in TPC-H Q18

Hi, On 2017-03-01 10:39:11 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 9:33 AM, Kuntal Ghosh > wrote: > > On Wed, Mar 1, 2017 at 9:19 AM, Andres Freund wrote: > >> That's without the patch in > >> http://archives.postgresql.org/message-id/2016

Re: [HACKERS] Performance degradation in TPC-H Q18

On 2017-03-01 11:05:33 +0530, Kuntal Ghosh wrote: > On Wed, Mar 1, 2017 at 10:53 AM, Andres Freund wrote: > > On 2017-03-01 10:47:45 +0530, Kuntal Ghosh wrote: > >> if (insertdist > curdist) > >> { > >> swap the entry to be inserted with the current entry.

Re: [HACKERS] Statement-level rollback

On 2017-03-03 11:54:06 -0500, David Steele wrote: > Given that this landed on March 28 with no discussion beforehand, I > recommend that we immediately move this patch to the 2017-07 CF. Seconded. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

Hi, On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote: > Since VM bits are only set during VACUUM which conflicts with CIC on the > relation lock, I don't see any risk of incorrectly skipping pages that the > second scan should have scanned. I think that's true currently, but it'd also prevent u

Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

On 2017-03-03 15:12:04 -0800, Peter Geoghegan wrote: > On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee > wrote: > > During the second heap scan of CREATE INDEX CONCURRENTLY, we're only > > interested in the tuples which were inserted after the first scan was > > started. All such tuples can only e

Re: [HACKERS] Performance degradation in TPC-H Q18

wrote: > On Fri, Mar 3, 2017 at 8:41 AM, Robert Haas wrote: > > On Fri, Mar 3, 2017 at 1:22 AM, Andres Freund wrote: > >> the resulting hash-values aren't actually meaningfully influenced by the > >> IV. Because we just xor with the IV, most hash-value that without the

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-01 22:19:30 -0800, Andres Freund wrote: > On 2017-03-02 04:36:23 +0100, Tomas Vondra wrote: > > I've noticed two minor typos: > > > > 1) That is solved this by creating ... > >- extra "this" > > > > 2) Given

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On March 4, 2017 1:16:56 AM PST, Robert Haas wrote: >Maybe. But it looks to me like this patch is going to have >considerably more than its share of user-visible warts, and I'm not >very excited about that. I feel like what we ought to be doing is >keeping the index OID the same and changing t

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Hi, On 2017-03-04 11:02:14 -0500, Tom Lane wrote: > But speaking of ambiguity: isn't it possible for $n symbols to appear in > pg_stat_statements already? Indeed. > I think it is, both from extended-protocol > client queries and from SPI commands, which would mean that the proposal > as it stand

Re: [HACKERS] ANALYZE command progress checker

On 2017-03-03 15:33:15 -0500, David Steele wrote: > On 3/1/17 1:25 PM, Andres Freund wrote: > > On 2017-03-01 10:20:41 -0800, David Fetter wrote: > >> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote: > >>> On 2/28/17 04:24, vinayak wrote: > >&

Re: [HACKERS] PATCH: two slab-like memory allocators

On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund wrote: > > The issue was that on 32bit platforms the Datum returned by some > > functions (int2int4_sum in this case) isn't actually a separately > > allocated Datum,

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, On 2017-03-06 19:49:56 +0100, Tomas Vondra wrote: > On 03/06/2017 07:05 PM, Robert Haas wrote: > > On Mon, Mar 6, 2017 at 12:44 PM, Andres Freund wrote: > > > On 2017-03-06 12:40:18 -0500, Robert Haas wrote: > > > > On Wed, Mar 1, 2017 at 5:55 PM, Andres Freund

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

Hi, This issue has bothered me in non-partitioned use-cases recently, so thanks for taking it up. On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote: > diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c > index 2fb9a8bf58..fa906e7930 100644 > --- a/src/backend/po

<    3   4   5   6   7   8   9   10   11   12   >