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:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #13846: INSERT ON CONFLICT consumes sequencersonconflicts
Next
From: Paul
Date:
Subject: Re: BUG #13846: INSERT ON CONFLICT consumes sequencers onconflicts