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

Michael Malis wrote: > 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-

Re: [HACKERS] psql --batch

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? The link between -qAtX and "batch" is not that fully obvious, especially the unaligned

[HACKERS] NoMovementScanDirection in heapgettup() and heapgettup_pagemode()

Hi all, I was trying to study NoMovementScanDirection part of heapgettup() and heapgettup_pagemode(). If I am right there is no test in test suit to hit this code. I did run make check-world could not hit it. Also, coverage report in https://coverage.postgresql.org/src/backend/access/heap/heapam.c.

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 2:28 PM, Craig Ringer wrote: > 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_reg

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 need more discussions ab

[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 you'd

[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 Developm

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 > done. Fixed this s

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 indirection is appropriat

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 are not opened. The attached patch does th

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, Julien Rouhaud wrote: > >> Patch attached. > > > > This was not

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 > improve-correlated-part

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 fo

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 active_pid IS NULL)" > +) > +

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 this patch with a wait query. > > Petr proposed

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 inactive"; + $stdout_recv = $nod

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 same problem at https://www.

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. It's not >> real clear why it seems to work 99.9

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: http://www.sraoss.co.jp/in

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 is?

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 and the backend. Ther

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 optimi

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

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 accompanyi

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 "STAR

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... 1

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 generate_series(1,10)::text ||