Re: [HACKERS] hash partitioning based on v10Beta2

On Sat, Aug 26, 2017 at 10:10 AM, yang...@highgo.com wrote: > Hi all, > > Now we have had the range / list partition, but hash partitioning is not > implemented yet. > Attached is a POC patch based on the v10Beta2 to add the > hash partitioning feature. > Although we will

[HACKERS] Make pg_regress print a connstring with sockdir

Hi all It's a pain having to find the postmaster command line to get the port pg_regress started a server on. We print the port in the pg_regress output, why not the socket directory / host? How about running on 'port=50848 host=/tmp/pg_regress-UMrcT3' with PID 16409 per the attached? If

[HACKERS] psql --batch

Hi all I find myself regurgitating the incantation psql -qAtX -v ON_ERRORS_STOP=1 quite a bit. It's not ... super friendly. It strikes me that we could possibly benefit from a 'psql --batch' option. Thoughts? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Sun, Aug 27, 2017 at 5:12 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > >> Attached latest v4 patch. Please review it. Thank you for reviewing this patch! > > Patch applies, compiles. > > The messages/options do not seem to work properly: > > sh> ./pgbench -i -I t

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

On 25 August 2017 at 15:12, Antonin Houska wrote: > Attached is a draft patch to allow extension to write log messages to a > separate file. I like the idea a lot. I'm not so sure about the approach. How will this play with syslog? csvlog? etc? I wonder if a level of

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

On Sun, Aug 27, 2017 at 12:16 PM, Tom Lane wrote: > Jeff Janes writes: >> It is easy to package 5 of those commands into a single PL/pgSQL function, >> with the other two being implicit via the standard auto-commit behavior >> when explicit transactions

Re: [HACKERS] Typo in insert.sgml

On 6/20/17 15:03, David G. Johnston wrote: > On Tuesday, June 20, 2017, Robert Haas > wrote: > > On Tue, Jun 20, 2017 at 2:34 PM, Peter Eisentraut > > wrote: > > On 6/18/17 03:16,

Re: [HACKERS] Re: Poor cost estimate with interaction between table correlation and partial indexes

Hmm... It seems the command I used for obtaining a patch I got from here https://wiki.postgresql.org/wiki/Working_with_Git truncated part of the patch. I've attached the file generated from git diff --patience master improve-partial-index-correlation-calculation --no-color >

Re: [HACKERS] Re: Poor cost estimate with interaction between table correlation and partial indexes

(Sorry David. I initially replied only to you) Ok. I've attached a patch of a proof-of-concept. I have a few questions about tests. What is typical workflow to add tests for changes to the planner? Also I ran make check and it appears one of the existing tests is failing. What is a typical way

Re: [HACKERS] More replication race conditions

On 28/08/17 01:36, Michael Paquier wrote: > On Sun, Aug 27, 2017 at 6:32 PM, Petr Jelinek > wrote: >> Attached should fix this. > > +$node_master->poll_query_until('postgres', > +"SELECT EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = > 'test_slot' AND

Re: [HACKERS] More replication race conditions

On Mon, Aug 28, 2017 at 8:33 AM, Tom Lane wrote: > Michael Paquier writes: >> Attached is a patch to make this code path wait that the transaction >> has been replayed. We could use as well synchronous_commit = apply, >> but I prefer the solution of

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 6:32 PM, Petr Jelinek wrote: > Attached should fix this. +$node_master->poll_query_until('postgres', +"SELECT EXISTS (SELECT 1 FROM pg_replication_slots WHERE slot_name = 'test_slot' AND active_pid IS NULL)" +) + or die "slot never became

Re: [HACKERS] More replication race conditions

Michael Paquier writes: > Attached is a patch to make this code path wait that the transaction > has been replayed. We could use as well synchronous_commit = apply, > but I prefer the solution of this patch with a wait query. Petr proposed a different patch to fix the

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 3:34 PM, Michael Paquier wrote: > On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane wrote: >> contains exactly no means of ensuring that the master's transaction has >> been replayed on the standby before we check for its results.

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

> Don't think anybody is proposing to remove the existing way to run > pgbench, so I'm not sure what your point is? I know. I just wanted to point out that the proposal is not good for cluster environment tests. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

Hi, On 2017-08-28 08:05:11 +0900, Tatsuo Ishii wrote: > With the proposed implementation it is not possible to do that kind of > test anymore since everything is packed into a function. Don't think anybody is proposing to remove the existing way to run pgbench, so I'm not sure what your point

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

> Jeff Janes writes: >> If all the data is in memory and you have a system with fast fsyncs (or are >> running with fsync off, or unlogged tables, or synchronous_commit off), >> then the big bottleneck in pgbench is the amount of back and forth between >> the pgbench program

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

I wrote: > I think that the correct fix probably involves marking each parallel scan > plan node as dependent on a pseudo executor parameter, which the parent > Gather or GatherMerge node would flag as being changed on each rescan. > This would cue the plan layers in between that they cannot

Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

I wrote: > 4. The fact that the test succeeds on many machines implies that the > leader process is usually doing *all* of the work. This is in itself not > very good. Even on the machines where it fails, the fact that the tuple > counts are usually a pretty large fraction of the expected values

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Hello, Here is the third version of the patch for pgbench thanks to Fabien Coelho comments. As in the previous one, transactions with serialization and deadlock failures are rolled back and retried until they end successfully or their number of tries reaches maximum. Here is some partial

Re: [HACKERS] Re: Poor cost estimate with interaction between table correlation and partial indexes

On Sat, Aug 26, 2017 at 05:50:26PM -0700, Michael Malis wrote: > Do you think this is a reasonable approach? Should I start working > on a patch based on the solution I described or is there some other > approach I should look into? You'll get more traction with a proof-of-concept patch

Re: [HACKERS] More replication race conditions

On 27/08/17 04:32, Noah Misch wrote: > On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: >> On 24/08/17 19:54, Tom Lane wrote: >>> sungazer just failed with >>> >>> pg_recvlogical exited with code '256', stdout '' and stderr >>> 'pg_recvlogical: could not send replication command

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Quick precision to my previous review. sh> ./pgbench -i -I t done. There should be "creating tables..." Does not seem to have initialized the tables although it was requested... sh> ./pgbench -i -I d creating tables... Probably "filling tables..." would be more appropriate. -- Fabien.

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Hello Masahiko-san, Attached latest v4 patch. Please review it. Patch applies, compiles. The messages/options do not seem to work properly: sh> ./pgbench -i -I t done. Does not seem to have initialized the tables although it was requested... sh> ./pgbench -i -I d creating tables...

Re: [HACKERS] type cache for concat functions

Hi 2017-08-24 19:24 GMT+02:00 Alexander Kuzmenkov : > Hi Pavel, > > I tried applying your patch, it applies and compiles fine, check and > checkworld pass. > > I ran a simple performance test, select concat(generate_series(1,10), > ... [x5 total]) vs select

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

About the patch: I'm generally in favor of providing more options to pgbench, especially if it can give optimization ideas to the performance conscious user. I think that the name should be "tpcb-like-plfunc": the script does not implement tpcb per spec, and such a function could be written

Re: [HACKERS] More replication race conditions

On Sun, Aug 27, 2017 at 12:03 PM, Tom Lane wrote: > And *another* replication test race condition just now: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi=2017-08-26%2019%3A37%3A08 > > As best I can interpret this, it's pointing out that this bit in >

Re: [HACKERS] Variable substitution in psql backtick expansion

Spending developer time to write code for the hypothetical someone running a psql version 11 linked to a libpq < 7.4, if it can even link, does not look like a very good investment... Anyway, here is required the update. The question is the server's version, not libpq. Ok. Modern psql does

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

Hello Tom, I dunno, it seems like this proposal involves jacking up the test case and driving a completely different one underneath. There is no reason to consider that you've improved the benchmark results --- you've just substituted a different benchmark, one with no historical basis, and