[HACKERS] <> join selectivity estimate question

Hi hackers, While studying a regression reported[1] against my parallel hash join patch, I noticed that we can also reach a good and a bad plan in unpatched master. One of the causes seems to be the estimated selectivity of a semi-join with an extra <> filter qual. Here are some times I

Re: [HACKERS] Protect syscache from bloating with negative cache entries

At Tue, 7 Mar 2017 19:23:14 -0800, David Steele wrote in <3b7b7f90-db46-8c37-c4f7-443330c3a...@pgmasters.net> > On 3/3/17 4:54 PM, David Steele wrote: > > > On 2/1/17 1:25 AM, Kyotaro HORIGUCHI wrote: > >> Hello, thank you for moving this to the next CF. > >> > >> At Wed, 1

Re: [HACKERS] Radix tree for character conversion

Thank you for committing this. At Mon, 13 Mar 2017 21:07:39 +0200, Heikki Linnakangas wrote in > On 03/13/2017 08:53 PM, Tom Lane wrote: > > Heikki Linnakangas writes: > >> It would be nice to run the map_checker

Re: [HACKERS] Speedup twophase transactions

On Thu, Mar 16, 2017 at 9:25 PM, Michael Paquier wrote: > On Thu, Mar 16, 2017 at 7:18 PM, Nikhil Sontakke > wrote: >>> + * * RecoverPreparedTransactions(), >>> StandbyRecoverPreparedTransactions() >>> + *and

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Mar 17, 2017 at 1:47 PM, Tsunakawa, Takayuki > wrote: > > BTW, does the developer of each feature have to modify the catalog version > in

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On Fri, Mar 17, 2017 at 1:47 PM, Tsunakawa, Takayuki wrote: > BTW, does the developer of each feature have to modify the catalog version in > catversion.h? It's a bit annoying to see the patch application failure on > catversion.h. Committers take care of this

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > The attached patch udpates the docs per your suggestion and has been rebased > on master at d69fae2. I made this ready for committer. The patch applied except for catversion.h, the

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Andres Freund writes: > On 2017-03-16 13:00:54 +0100, Petr Jelinek wrote: >> Looks like that didn't help either. >> >> I setup my own Windows machine and can reproduce the issue. I played >> around a bit and could not really find a fix other than adding >> WL_TIMEOUT and

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 2017-03-16 13:00:54 +0100, Petr Jelinek wrote: > On 15/03/17 17:55, Tom Lane wrote: > > Andrew Dunstan writes: > >> On 03/03/2017 11:11 PM, Tom Lane wrote: > >>> Yeah, I was wondering if this is just exposing a pre-existing bug. > >>> However, the "normal" path

Re: [HACKERS] scram and \password

On Thu, Mar 16, 2017 at 10:52 PM, Heikki Linnakangas wrote: > On 03/14/2017 11:14 PM, Tom Lane wrote: >> >> In short, I don't think that argument refutes my position that "md5" >> in pg_hba.conf should be understood as allowing SCRAM passwords too. > > > Yeah, let's do that.

Re: [HACKERS] WAL Consistency checking for hash indexes

On Thu, Mar 16, 2017 at 1:15 PM, Ashutosh Sharma wrote: > Hi, > > Attached is the patch that allows WAL consistency tool to mask > 'LH_PAGE_HAS_DEAD_TUPLES' flag in hash index. The flag got added as a > part of 'Microvacuum support for Hash index' patch . I have already >

Re: [HACKERS] logical replication launcher crash on buildfarm

On 3/16/17 14:55, Andres Freund wrote: > I indeed think that's the right consequence. One question is what to > replace it with exactly - are we guaranteed we can dynamically lookup > symbols by name in the main binary on every platform? I think there is probably a way to do this on all

Re: [HACKERS] possible encoding issues with libxml2 functions

On Sun, Mar 12, 2017 at 10:26:33PM +0100, Pavel Stehule wrote: > 2017-03-12 21:57 GMT+01:00 Noah Misch : > > On Sun, Mar 12, 2017 at 08:36:58PM +0100, Pavel Stehule wrote: > > > 2017-03-12 0:56 GMT+01:00 Noah Misch : > > Please add a test case. > > It needs a

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

On 3/16/17 11:56, Alvaro Herrera wrote: > Michael Paquier wrote: > >> What are you using as CFLAGS? As both typenames should be normally >> set, what about initializing those fields with NULL and add an >> assertion like the attached? > > Actually, my compiler was right -- this was an ancient

Re: [HACKERS] multivariate statistics (v25)

On 17 March 2017 at 11:20, Alvaro Herrera wrote: > (I think I lost some regression test files. I couldn't make up my mind > about putting each statistic type's tests in a separate file, or all > together in stats_ext.sql.) +1 for stats_ext.sql. I wanted to add some

Re: [HACKERS] Microvacuum support for Hash Index

On Thu, Mar 16, 2017 at 9:39 PM, Ashutosh Sharma wrote: >>> >> >> Don't you think, we should also clear it during the replay of >> XLOG_HASH_DELETE? We might want to log the clear of flag along with >> WAL record for XLOG_HASH_DELETE. >> > > Yes, it should be cleared. I

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

On 16 March 2017 at 19:52, Stas Kelvich wrote: > > I’m working right now on issue with building snapshots for decoding prepared > tx. > I hope I'll send updated patch later today. Great. What approach are you taking? It looks like the snapshot builder actually does

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

On 17 March 2017 at 08:10, Stas Kelvich wrote: > While working on this i’ve spotted quite a nasty corner case with aborted > prepared > transaction. I have some not that great ideas how to fix it, but maybe i > blurred my > view and missed something. So want to ask

Re: [HACKERS] Potential data loss of 2PC files

On Thu, Mar 16, 2017 at 10:17 PM, David Steele wrote: > On 2/13/17 12:10 AM, Michael Paquier wrote: >> On Tue, Jan 31, 2017 at 11:07 AM, Michael Paquier >> wrote: >>> On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas >>>

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote: > I understand that the point of renaming pg_clog to pg_xact is that > pg_clog contains the dreaded letters l-o-g, which we hypothesize > causes DBAs to remove it. (Alternate hypothesis: "So, that's what's > clogging my

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Thu, Mar 16, 2017 at 9:31 PM, Michael Paquier wrote: > On Fri, Mar 17, 2017 at 12:19 AM, David Steele wrote: >> This patch does not apply cleanly at cccbdde: >> >> $ git apply ../other/0001-Rename-pg_clog-to-pg_xact.patch >> error:

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

On Fri, Mar 17, 2017 at 3:38 AM, Michael Banck wrote: >> Your patch would work with the stream mode though. > > Or, if not requesting the "WAL" option of the replication protocol's > BASE_BACKUP command. > > I agree it doesn't make sense to start messing with fetch

Re: [HACKERS] ANALYZE command progress checker

On Fri, Mar 10, 2017 at 2:46 AM, vinayak wrote: > Thank you for reviewing the patch. > > The attached patch incorporated Michael and Amit comments also. I reviewed this tonight. +/* Report compute index stats phase */ +

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Mar 17, 2017 at 12:19 AM, David Steele wrote: > This patch does not apply cleanly at cccbdde: > > $ git apply ../other/0001-Rename-pg_clog-to-pg_xact.patch > error: doc/src/sgml/ref/pg_resetxlog.sgml: No such file or directory > error: patch failed:

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Attached is the latest work. Not everything is done yet. I post it because the next step is likely to be "tedious" as Tom put it, and if there's a way out of it, I want to avoid it. What is done: - all changes here built off the v22 patch - any function which had scan_state and cond_stack passed

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On Fri, Mar 17, 2017 at 2:30 AM, Jeff Janes wrote: > On Thu, Mar 9, 2017 at 4:59 AM, Michael Paquier > wrote: >> >> On Thu, Mar 9, 2017 at 1:17 AM, Joe Conway wrote: >> > On 03/07/2017 08:29 PM, Tom Lane wrote: >> >> Michael

Re: [HACKERS] increasing the default WAL segment size

On Tue, Mar 14, 2017 at 1:44 AM, Beena Emerson wrote: > Attached is the updated patch. It fixes the issues and also updates few code > comments. I did an initial readthrough of this patch tonight just to get a feeling for what's going on. Based on that, here are a few

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

From: David Steele [mailto:da...@pgmasters.net] > Any idea when you'll have a chance to review? I'll do it by early next week. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

>> On 2 Mar 2017, at 11:00, Craig Ringer wrote: >> >> BTW, I've been reviewing the patch in more detail. Other than a bunch >> of copy-and-paste that I'm cleaning up, the main issue I've found is >> that in DecodePrepare, you call: >> >>

Re: [HACKERS] \h tab-completion

On 03/17/2017 12:01 AM, Peter Eisentraut wrote: Committed with some tweaking. Thanks! Andreas -- 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] \h tab-completion

On 3/15/17 22:46, Andreas Karlsson wrote: > On 03/01/2017 02:47 PM, Peter Eisentraut wrote: >> Instead of creating another copy of list_ALTER, let's use the >> words_after_create list and write a version of >> create_command_generator/drop_command_generator. > > Good idea. Here is a patch with

[HACKERS] [PATCH] Remove defunct and unnecessary link

The HA docs reference a “glossary” link which is no longer accessible, nor is it likely to be useful in general to link off-site IMHO. This simple patch removes this link. Best, David -- David Christensen End Point Corporation da...@endpoint.com 785-727-1171

Re: [HACKERS] BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: Heikki Linnakangas So, I think we still need the check for Local System. Thanks, fixed and confirmed that the error message is output in the event log. Regards MauMau win32-security-service-v7.patch Description: Binary data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Size vs size_t

Thomas Munro writes: > Naive replacement in new files (present in master but not in 9.6) with > the attached script, followed by a couple of manual corrections where > Size was really an English word in a comment, gets the attached diff. In the case of mmgr/slab.c,

Re: [HACKERS] Size vs size_t

On Fri, Mar 17, 2017 at 10:39 AM, Andres Freund wrote: > On 2017-03-16 17:24:17 -0400, Tom Lane wrote: >> Robert Haas writes: >> > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund wrote: >> >> On 2017-03-16 16:59:29 -0400, Robert Haas

Re: [HACKERS] Size vs size_t

Andres Freund writes: > On 2017-03-16 17:24:17 -0400, Tom Lane wrote: >> The short answer to that is that "Size" predates the universal acceptance >> of size_t. If we were making these decisions today, or anytime since the >> early 2000s, we'd surely have just gone with

Re: [HACKERS] Making clausesel.c Smarter

David Steele writes: > Anyone familiar with the planner available to review this patch? FWIW, it's on my radar but I don't expect to get to it real soon, as there's other stuff I deem higher priority. In the meantime, I don't want to stand in the way of someone else looking

Re: [HACKERS] Making clausesel.c Smarter

On 2/26/17 1:41 AM, Robert Haas wrote: > On Fri, Feb 24, 2017 at 3:30 PM, David Rowley > wrote: >> It would be good to improve the situation here in the back branches >> too, but I'm thinking that the attached might be a little invasive for >> that? > > My

Re: [HACKERS] Size vs size_t

On 2017-03-16 17:24:17 -0400, Tom Lane wrote: > Robert Haas writes: > > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund wrote: > >> On 2017-03-16 16:59:29 -0400, Robert Haas wrote: > >>> I guess I assumed that we wouldn't have defined PG-specific types

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 2/25/17 1:27 PM, Peter Eisentraut wrote: > Something that has been bothering me in PL/Python for a long time is the > non-object-oriented way in which plans are prepared and executed: > > plan = plpy.prepare(...) > res = plpy.execute(plan, ...) > > where plpy.execute() takes either a

[HACKERS] Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.

On 1/25/17 2:58 PM, Fabien COELHO wrote: > > Repost from bugs. This patch does not apply at cccbdde: $ patch -p1 < ../other/pgbench-CR-bug-1.patch (Stripping trailing CRs from patch.) patching file src/bin/pgbench/pgbench.c Hunk #1 FAILED at 1967. Hunk #2 succeeded at 4180 with fuzz 2 (offset

Re: [HACKERS] Size vs size_t

Robert Haas writes: > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund wrote: >> On 2017-03-16 16:59:29 -0400, Robert Haas wrote: >>> I guess I assumed that we wouldn't have defined PG-specific types if >>> we wanted to just use the OS-supplied ones. >>

Re: [HACKERS] asynchronous execution

On Thu, Mar 16, 2017 at 4:17 PM, Tom Lane wrote: > Corey Huinker writes: > > I reworked the test such that all of the foreign tables inherit from the > > same parent table, and if you query that you do get async execution. But > It > > doesn't work

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: > Ok, I've got some time now and I'm starting to dig into this. I'd like to > restate what I *think* my feedback is, in case I missed or misunderstood > something. > ... > 3. Change command scans to scan the whole boolean expression, not just >

Re: [HACKERS] Size vs size_t

On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund wrote: > On 2017-03-16 16:59:29 -0400, Robert Haas wrote: >> On Thu, Mar 16, 2017 at 4:40 PM, Thomas Munro >> wrote: >> > Noticing that the assembled hackers don't seem to agree on $SUBJECT in >> >

[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2017-03-15 17:21 GMT+01:00 Stephen Frost : > > I started looking through this to see if it might be ready to commit and > > I don't believe it is. Below are my comments about the first patch, I > > didn't get to the

Re: [HACKERS] Size vs size_t

On 2017-03-16 16:59:29 -0400, Robert Haas wrote: > On Thu, Mar 16, 2017 at 4:40 PM, Thomas Munro > wrote: > > Noticing that the assembled hackers don't seem to agree on $SUBJECT in > > new patches, I decided to plot counts of lines matching \ and > >

Re: [HACKERS] Size vs size_t

On Thu, Mar 16, 2017 at 4:40 PM, Thomas Munro wrote: > Noticing that the assembled hackers don't seem to agree on $SUBJECT in > new patches, I decided to plot counts of lines matching \ and > \ over time. After a very long run in the lead, size_t

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 13, 2017 at 5:21 PM, Tom Lane wrote: > "Daniel Verite" writes: > > Tom Lane wrote: > >> when we see \if is that we do nothing but absorb text > >> until we see the matching \endif. At that point we could bitch and > throw > >> everything

Re: [HACKERS] GSOC - TOAST'ing in slices

George, * George Papadrosou (gpapadro...@gmail.com) wrote: > Stephen, you mentioned PostGIS, but the conversation seems to lean towards > JSONB. What are your thoughts? Both are important. I brought up PostGIS specifically because it's an external project which could benefit from this work and

[HACKERS] Size vs size_t

Hi, Noticing that the assembled hackers don't seem to agree on $SUBJECT in new patches, I decided to plot counts of lines matching \ and \ over time. After a very long run in the lead, size_t has recently been left in the dust by Size. -- Thomas Munro

Re: [HACKERS] asynchronous execution

Corey Huinker writes: > I reworked the test such that all of the foreign tables inherit from the > same parent table, and if you query that you do get async execution. But It > doesn't work when just stringing together those foreign tables with UNION > ALLs. > I don't

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 16, 2017 at 6:27 AM, Amit Khandekar wrote: > Attached is an updated patch v7, which does the above. Some comments: - You've added a GUC (which is good) but not documented it (which is bad) or added it to postgresql.conf.sample (also bad). - You've used a

[HACKERS] temp_buffers vs temp vs local and explain

-hackers, I was reviewing an explain plan today and with some help from Andrew G, I got a lot more information than I deserved. It did however bring up quite a usability issue that I think we should consider. Let's review the following two lines: Sort Method: external merge Disk: 19352kB

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 16, 2017 at 8:48 AM, Ashutosh Bapat wrote: > Why do we need following code in both ExecAppendInitializeWorker() and > ExecAppendInitializeDSM()? Both of those things happen before starting the > actual execution, so one of those should suffice? > +

Re: [HACKERS] logical replication launcher crash on buildfarm

On Thu, Mar 16, 2017 at 2:55 PM, Andres Freund wrote: > I indeed think it's not safe, and it's going to get less and less safe > on windows (or EXEC_BACKEND). I don't think we can afford to disable > ASLR in the long run (I indeed supect that'll just be disallowed at some >

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 1:50 PM, Dilip Kumar wrote: > fixed Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] pg_ls_waldir() & pg_ls_logdir()

On Thu, Mar 16, 2017 at 6:09 AM, Dave Page wrote: > Hmm, good point. Google seems to be saying there isn't one. Patch > updated as you suggest (and I've added back in a function declaration > that got lost in the rebasing of the last version). OK, I took another look at this:

Re: [HACKERS] Monitoring roles patch

Hi Dave, The patch failed applied... patch -p1 < /home/vagrant/pg_monitor.diff patching file contrib/pg_buffercache/Makefile patching file contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql patching file contrib/pg_buffercache/pg_buffercache.control patching file

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-03-16 23:55 GMT+05:00 Peter Geoghegan : > On Thu, Mar 16, 2017 at 11:53 AM, Andrew Borodin wrote: >> 2. Thus, L fully concurrent vacuum is possible, indeed, and >> furthermore Theodor suggested that I should implement not only page >> eviction, but also

Re: [HACKERS] pgbench more operators & functions

Hello David, This patch applies cleanly and compiles at cccbdde with some whitespace issues. $ patch -p1 < ../other/pgbench-more-ops-funcs-9.patch (Stripping trailing CRs from patch.) My guess is that your mailer changed the eol-style of the file when saving it: sh> sha1sum

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On Thu, Mar 16, 2017 at 11:53 AM, Andrew Borodin wrote: > 2. Thus, L fully concurrent vacuum is possible, indeed, and > furthermore Theodor suggested that I should implement not only page > eviction, but also page merge and tree condence algorithm. I think that it's very

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:27:59 -0400, Robert Haas wrote: > On Thu, Mar 16, 2017 at 5:13 AM, Petr Jelinek > wrote: > > Hmm now that you mention it, I remember discussing something similar > > with you last year in Dallas in regards to parallel query. IIRC Windows > > should

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-03-16 21:27 GMT+05:00 David Steele : > This patch applies cleanly and compiles at cccbdde. > > Jeff, any thoughts on Andrew's responses? Hi, David! I've got some updates on the matter of this patch, since the understanding of the B-tree bothered me much. Currently, I'm

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Hi, sorry, it took me a while to get back to this. Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier: > On Wed, Feb 22, 2017 at 9:23 PM, Bernd Helmle wrote: > > The comment in the code says explicitely to add the base directory to > > the end of the list, not

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 8:26 PM, Emre Hasegeli wrote: >> Hopefully, this time I got it correct. Since I am unable to reproduce >> the issue so I will again need your help in verifying the fix. > > It is not crashing with the new patch. Thank you. Thanks for verifying. --

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 8:42 PM, Robert Haas wrote: > Thanks for confirming. Some review comments on v2: > > +if (istate->pagetable) fixed > > Please compare explicitly to InvalidDsaPointer. > > +if (iterator->ptbase) > +ptbase = iterator->ptbase->ptentry;

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On 2/4/17 2:47 PM, Alexander Korotkov wrote: > On Sat, Feb 4, 2017 at 4:33 AM, Andres Freund > wrote: > > On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > > No, I noticed it while reading code. Removing that does mean that if any > >

Re: [HACKERS] Push down more full joins in postgres_fdw

On Thu, Mar 16, 2017 at 12:48 PM, Robert Haas wrote: > On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote: >> $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch >> patching file contrib/postgres_fdw/deparse.c >> Hunk #11 succeeded at 1371

Re: [HACKERS] LWLock optimization for multicore Power machines

On 2/21/17 9:54 AM, Bernd Helmle wrote: > Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: >> +1 >> And you could try to use pg_wait_sampling >> to sampling of wait >> events. > > I've tried this with your example from your

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On Thu, Mar 9, 2017 at 4:59 AM, Michael Paquier wrote: > On Thu, Mar 9, 2017 at 1:17 AM, Joe Conway wrote: > > On 03/07/2017 08:29 PM, Tom Lane wrote: > >> Michael Paquier writes: > >>> here is a separate thread

Re: [HACKERS] [POC] A better way to expand hash indexes.

On 2/21/17 4:58 AM, Mithun Cy wrote: > Thanks, Amit > > On Mon, Feb 20, 2017 at 9:51 PM, Amit Kapila wrote: >> How will high and lowmask calculations work in this new strategy? >> Till now they always work on doubling strategy and I don't see you >> have changed anything

Re: [HACKERS] GSOC - TOAST'ing in slices

Hello all, thank you for your replies. I agree with Alexander Korotkov that it is important to have a quality patch at the end of the summer. Stephen, you mentioned PostGIS, but the conversation seems to lean towards JSONB. What are your thoughts? Also, if I am to include some

Re: [HACKERS] asynchronous execution

On Mon, Mar 13, 2017 at 9:28 PM, Amit Langote wrote: > On 2017/03/14 10:08, Corey Huinker wrote: > >> I don't think the plan itself will change as a result of applying this > >> patch. You might however be able to observe some performance > improvement. > > > > I

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

On 2/14/17 4:03 PM, Tom Lane wrote: > Jim Nasby writes: >> On 2/14/17 1:18 PM, Tom Lane wrote: >>> One point that could use further review is whether the de-duplication >>> algorithm is actually correct. I'm only about 95% convinced by the >>> argument I wrote in

Re: [HACKERS] Push down more full joins in postgres_fdw

On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote: > $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch > patching file contrib/postgres_fdw/deparse.c > Hunk #11 succeeded at 1371 (offset -3 lines). > Hunk #12 succeeded at 1419 (offset -3 lines). > Hunk #13

Re: [HACKERS] Potential data loss of 2PC files

On 2/13/17 12:10 AM, Michael Paquier wrote: > On Tue, Jan 31, 2017 at 11:07 AM, Michael Paquier > wrote: >> On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote: >>> If that can happen, don't we have the same problem in many other places? >>>

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Thu, Mar 16, 2017 at 12:39 PM, David Steele wrote: >> Anyway, I committed the patch posted here. Or the important line out >> of the two, anyway. :-) > > It seems that this submission should be marked as "Committed" with > Robert as the committer. Am I missing

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 3/16/17 12:41 PM, Robert Haas wrote: > On Thu, Mar 16, 2017 at 12:39 PM, David Steele wrote: >>> Anyway, I committed the patch posted here. Or the important line out >>> of the two, anyway. :-) >> >> It seems that this submission should be marked as "Committed" with >>

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/2/17 2:47 PM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby wrote: >> Before doing that the first thing to look at would be why the limit is >> currently INT_MAX / 2 instead of INT_MAX. > > Generally the rationale for GUCs with limits of that sort

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On 2/5/17 11:04 AM, Andrew Borodin wrote: > Hi, Jeff! > > 2017-02-05 3:45 GMT+05:00 Jeff Davis : >> On Sun, Jan 22, 2017 at 10:32 PM, Jeff Davis wrote: >>> On Sat, Jan 21, 2017 at 4:25 AM, Andrew Borodin >>> wrote: >>> One idea I had

Re: [HACKERS] pgbench more operators & functions

On 2/4/17 4:51 AM, Fabien COELHO wrote: > > Hello, > >> For my 2c, at least, while I'm definitely interested in this, it's not >> nearly high enough on my plate with everything else going on to get any >> attention in the next few weeks, at least. >> >> I do think that, perhaps, this patch may

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 2/1/17 3:59 PM, Pavel Stehule wrote: > Hi > > 2017-01-24 21:33 GMT+01:00 Pavel Stehule >: > > Perhaps that's as simple as renaming all the existing _ns_* > functions to _block_ and then adding support for

[HACKERS] Re: Floating point comparison inconsistencies of the geometric types

On 2/1/17 6:36 AM, Emre Hasegeli wrote: >> Got it, but if other people don't agree then this is going nowhere. > > Yes. As I wrote, I don't particularly care about functions like "is > point on line". I can prepare a patch to fix as many problems as > possible around those operators by

Re: [HACKERS] Microvacuum support for Hash Index

>>> Sure, but we are not clearing in conditionally. I am not sure, how >>> after recovery it will be cleared it gets set during normal operation. >>> Moreover, btree already clears similar flag during replay (refer >>> btree_xlog_delete). >> >> You were right. In case datachecksum is enabled or

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 2, 2017 at 12:24 PM, David Fetter wrote: >> Also, somebody who wants a check like that isn't necessarily going >> to want "no WHERE clause" training wheels. So you're going to need >> to think about facilities to enable or disable different checks. > > This is just

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

Michael Paquier wrote: > What are you using as CFLAGS? As both typenames should be normally > set, what about initializing those fields with NULL and add an > assertion like the attached? Actually, my compiler was right -- this was an ancient bug I introduced in 9.5 (commit a61fd533), and this

[HACKERS] Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On 3/16/17 11:53 AM, Jon Nelson wrote: > > > On Thu, Mar 16, 2017 at 9:59 AM, David Steele > wrote: > > On 1/9/17 11:33 PM, Jon Nelson wrote: > > > > On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Mon, Jan 9, 2017 at 4:27 PM, Jonathon Nelson wrote: > [I have not done a rigid analysis, here, but...] > > I *think* libpq is the culprit here. > > walsender says "Hey, libpq - please send (up to) 128KB of data!" and doesn't > "return" until it's "sent". Then it sends more.

Re: [HACKERS] PATCH: recursive json_populate_record()

On 2/1/17 12:53 AM, Michael Paquier wrote: > On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote: >> Nikita Glukhov writes: >>> On 25.01.2017 23:58, Tom Lane wrote: I think you need to take a second look at the code you're producing and realize

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Thu, Mar 16, 2017 at 9:59 AM, David Steele wrote: > On 1/9/17 11:33 PM, Jon Nelson wrote: > > > > On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby > > wrote: > > > > On 1/5/17 12:55 PM, Jonathon Nelson wrote: > > >

Re: [HACKERS] WIP: Faster Expression Processing v4

I wrote: > Andres Freund writes: >> I don't think there's a danger similar to f0c7b789a here, because the >> "caller" (i.e. the node that needs the expression's result) expects >> resvalue/null to be overwritten. > Yeah, that's what I thought when I wrote the broken code in

Re: [HACKERS] Push down more full joins in postgres_fdw

On 1/30/17 6:30 AM, Etsuro Fujita wrote: > On 2017/01/27 21:25, Etsuro Fujita wrote: >> On 2017/01/27 20:04, Ashutosh Bapat wrote: >>> I think we should pick up your patch on >>> 27th December, update the comment per your mail on 5th Jan. I will >>> review it once and list down the things left to

Re: [HACKERS] postgres_fdw bug in 9.6

On 1/23/17 4:56 AM, Etsuro Fujita wrote: > On 2017/01/20 14:24, Ashutosh Bapat wrote: >> On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas >> wrote: >>> On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat >>> wrote: > Yes, I think that's

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 1/17/17 2:31 AM, Michael Paquier wrote: > On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier > wrote: >> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi >> wrote: >>> Hi Craig, >>> >>> This is a gentle reminder. >>> >>> you assigned as

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 20:09:03 -0400, Tom Lane wrote: >> That scares me quite a bit, because it smells exactly like the sort of >> premature optimization that bit us on the rear in CVE-2016-5423 (cf commit >> f0c7b789a). > I don't think there's a danger

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 16, 2017 at 10:56 AM, Emre Hasegeli wrote: >> Hopefully, this time I got it correct. Since I am unable to reproduce >> the issue so I will again need your help in verifying the fix. > > It is not crashing with the new patch. Thank you. Thanks for confirming.

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On 12/20/16 2:54 AM, Michael Paquier wrote: > On Sat, Dec 17, 2016 at 9:23 PM, Magnus Hagander wrote: >> On Fri, Dec 16, 2016 at 7:08 AM, Michael Paquier >> wrote: >>> Looking at PrescanPreparedTransactions(), I am thinking as well that it >>>

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

On Thu, Mar 16, 2017 at 7:19 AM, Ashutosh Bapat wrote: > On Thu, Mar 16, 2017 at 7:10 AM, Robert Haas wrote: >> So I am looking at this part of 0008: >> >> + /* >> +* Do not copy parent_rinfo and child_rinfos because 1. they

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

On Thu, Mar 16, 2017 at 6:48 AM, Ashutosh Bapat wrote: >> I thought the whole point here was that NOT doing that caused the >> memory usage for partitionwise join to get out of control. Am I >> confused? > > We took a few steps to reduce the memory footprint of

  1   2   >