BUG #13852: SQL Select Slow Issues - Mailing list pgsql-bugs
From | eugeneymail@ymail.com |
---|---|
Subject | BUG #13852: SQL Select Slow Issues |
Date | |
Msg-id | 20160106204250.1117.54966@wrigleys.postgresql.org Whole thread Raw |
Responses |
Re: BUG #13852: SQL Select Slow Issues
Re: BUG #13852: SQL Select Slow Issues Re: BUG #13852: SQL Select Slow Issues |
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 13852 Logged by: Eugene Email address: eugeneymail@ymail.com PostgreSQL version: 9.4.5 Operating system: Linux Description: I have been a long time Oracle user. Currently I am thinking to switch to PostgreSQL. So I did a lot searches/researches on this product. The general and major complains I can summarize is the "SELECT" statement returns results too slow, as compared to the commercialized products such as Oracle and MS SQL Server. So I would like to submit some suggestions: 1) During the installation process, use a GUI window to let the user choose: (a) For OLTP use (b) For General Purpose (c) Customized Installation For type (a) installation, automatically use the preset and optimised paramters targeted at the OLTP system; For type (b) installation, automatically use the preset and optimised paramters targeted at the general system; For type (c) installation, automatically use the preset paramters just like those in releases, it will up to the user to tune those parameters lateron, by themselves; Otherwise, it will create challenges to users in their installation of PostgresSQL. This is because we do not know which parameters to set or adjust, there could be hundres if not thousands componations of them. If I want to set up an OLAP system on PostgresSQL, I will not know which parameters to choose and set to achieve reasonably better performance. In the case of Oracle, the thing is different. Quite frankly, it is a no brainer that if I want the database to be used for an OLTP system, I just choose OLTP, the parameters underneath have already been preset and opertimised by Oracle. 2) The speed issue. I know the features are important and in every release, new features are introduced. Those are good. But in my opinion, the far most important thing is to increase the speed. More often than not people view a better DBMS product is not because it have this or that fancy feature but the speed. Yes the speed that wins the day. The bells and whistles look nice and shining. But without the tree, they are just some shining pieces of glass or metal. As the users, we want to tree! The following I list some links of the sites which complains the sluggish of the PostgreSQL for future reference: Starting with the quote from https://wiki.postgresql.org/wiki/Slow_Query_Questions âIn any given week, some 50% of the questions on #postgresql IRC and 75% on pgsql-performance are requests for help with a slow query.â Count Distinct Compared on Top 4 SQL Databases https://www.periscopedata.com/blog/count-distinct-in-mysql-postgres-sql-server-and-oracle.html Select * is very slow http://postgresql.nabble.com/Select-is-very-slow-td3254568.html postgresql simple select is slow http://stackoverflow.com/questions/9019797/postgresql-simple-select-is-slow Slow select - PostgreSQL http://stackoverflow.com/questions/18508866/slow-select-postgresql PosgreSQL: very slow select on a single table with no joins http://dba.stackexchange.com/questions/73677/posgresql-very-slow-select-on-a-single-table-with-no-joins postgresql simple select is slow http://stackoverflow.com/questions/9019797/postgresql-simple-select-is-slow PostgreSQL queries slower than before? http://serverfault.com/questions/644980/postgresql-queries-slower-than-before Very slow column count on large Postgres tabls http://www.heidisql.com/forum.php?t=17959
pgsql-bugs by date: