BUG #13852: SQL Select Slow Issues

Поиск
Список
Период
Сортировка
От eugeneymail@ymail.com
Тема BUG #13852: SQL Select Slow Issues
Дата
Msg-id 20160106204250.1117.54966@wrigleys.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #13852: SQL Select Slow Issues  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Re: BUG #13852: SQL Select Slow Issues  (Thomas Kellerer <spam_eater@gmx.net>)
Re: BUG #13852: SQL Select Slow Issues  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #13846: INSERT ON CONFLICT consumes sequencersonconflicts
Следующее
От: Paul
Дата:
Сообщение: Re: BUG #13846: INSERT ON CONFLICT consumes sequencers onconflicts