Comments on: Parallelism in PostgreSQL https://www.percona.com/blog/parallelism-in-postgresql/ Fri, 19 Jan 2024 23:51:17 +0000 hourly 1 https://wordpress.org/?v=6.5.2 By: Lynn P. Tilby https://www.percona.com/blog/parallelism-in-postgresql/#comment-10972232 Sat, 16 May 2020 09:58:19 +0000 https://www.percona.com/blog/?p=59225#comment-10972232 How do I set up a query to use multiple workers?

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971503 Thu, 28 Nov 2019 19:36:26 +0000 https://www.percona.com/blog/?p=59225#comment-10971503 Don’t worry about PostgreSQL.NNNNN file, it is for internal use. The “NNNNN” is a internal handle information. You only need to worry about shared_buffers. a

]]> By: leiyanliang https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971467 Thu, 21 Nov 2019 08:27:33 +0000 https://www.percona.com/blog/?p=59225#comment-10971467 hi,Ibrar,
I find the following:
when I execute a large query which use parallel(pg version is 10 or 11), at the same time， there are some file created in the /dev/shm/ directory， and file name is “PostgreSQL.NNNNNNNNN”，
I want to know：
1. What is the file PostgreSQL.NNNNNNNNN ，and what does NNNNNNNNN mean？
2.If this file(PostgreSQL.NNNNNNNNN) is about parallel, and if the PG has very high parallel throughouts, should we set the large /dev/shm ?

]]> By: Tim https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971096 Sat, 10 Aug 2019 23:59:13 +0000 https://www.percona.com/blog/?p=59225#comment-10971096 “PostgreSQL is one of the finest object-relational databases”

It’s the only database I’ve ever heard describe itself as “object-relational”, and its object features are so weak and unmaintained that its own manual suggests avoiding them.

Let’s call a spade a spade. It’s a relational database.

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971051 Tue, 30 Jul 2019 16:39:21 +0000 https://www.percona.com/blog/?p=59225#comment-10971051 Thanks for your input.

]]> By: Derek https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971050 Tue, 30 Jul 2019 16:35:26 +0000 https://www.percona.com/blog/?p=59225#comment-10971050 I like how that looks, it matches up with what you are describing and helps reinforce the comment about reaching a limit of how throwing more workers at the problem will eventually have a negative effect.

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971049 Tue, 30 Jul 2019 16:23:32 +0000 https://www.percona.com/blog/?p=59225#comment-10971049 To remove the confusion, lets draw that in increasing order

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971048 Tue, 30 Jul 2019 16:09:21 +0000 https://www.percona.com/blog/?p=59225#comment-10971048 One more thing, a slight variation in benchmark is expected, even I did that multiple time and took the median to remove the ourlier.

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971047 Tue, 30 Jul 2019 16:07:28 +0000 https://www.percona.com/blog/?p=59225#comment-10971047 No, data is correct, Here is the complete dataset I have for the first graph

Workers Execution Time (ms)
10 1182976
9 1098745
8 1382642
7 1561483
6 1764753
5 1855142
4 2009847
3 2012568
2 2164726
1 2285845
0 2288745

]]> By: Derek https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971046 Tue, 30 Jul 2019 15:59:52 +0000 https://www.percona.com/blog/?p=59225#comment-10971046 I don’t think that swapping the Worker legend fixed it. I don’t have your source data from your tests, but from your explanation it took 4343080ms to run the sequential scan without parallelism. When you add one worker it makes sense that the cost will increase slightly since you have the added overhead of the gather process. After that the cost should decrease down to a final speed of 1628295ms with 10 workers.

The line on your graph tells that story but in reverse, showing a slight decrease with that addition of the gather process and then a steady increase as workers are added with a final diminishing return when you reach 10 workers. I feel that by reversing the direction of the Workers legend it just added confusion to the graph.

I believe the graph should be downward sloping to the right, with the X axis increasing from 0 to 10 like in the original version. What caught my eye when I was originally reading the article what that the data points from your description didn’t match up with the Y axis legend

]]> By: Ibrar Ahmed https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971044 Tue, 30 Jul 2019 15:29:48 +0000 https://www.percona.com/blog/?p=59225#comment-10971044 Thanks Derek, Its was typo and fixed.

]]> By: Derek https://www.percona.com/blog/parallelism-in-postgresql/#comment-10971043 Tue, 30 Jul 2019 15:18:26 +0000 https://www.percona.com/blog/?p=59225#comment-10971043 Great explanation, but I noticed that your graphs seem to be showing the opposite of what you are saying. The more workers you add the lower the Query Execution Time, as I am currently reading the graph it looks like the query is taking longer the more workers you have.

]]>