Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Grant Johnson
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id 4D4BF99D.7050901@amadensor.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: [HACKERS] Slow count(*) again...
Список pgsql-performance
> Yes.  And this has little to do with hints.  It has to do with years
> of development lead with THOUSANDS of engineers who can work on the
> most esoteric corner cases in their spare time.  Find the pg project a
> couple hundred software engineers and maybe we'll catch Oracle a
> little quicker.  Otherwise we'll have to marshall our resources to do
> the best we can on the project ,and that means avoiding maintenance
> black holes and having the devs work on the things that give the most
> benefit for the cost.  Hints are something only a tiny percentage of
> users could actually use and use well.
>
> Write a check, hire some developers and get the code done and present
> it to the community.  If it's good and works it'll likely get
> accepted.  Or use EDB, since it has oracle compatibility in it.
>
I have to disagree with you here.   I have never seen Oracle outperform
PostgreSQL on complex joins, which is where the planner comes in.
Perhaps on certain throughput things, but this is likely do to how we
handle dead rows, and counts, which is definitely because of how dead
rows are handled, but the easier maintenance makes up for those.  Also
both of those are by a small percentage.

I have many times had Oracle queries that never finish (OK maybe not
never, but not over a long weekend) on large hardware, but can be
finished on PostgreSQL in a matter or minutes on cheap hardware.   This
happens to the point that often I have set up a PostgreSQL database to
copy the data to for querying and runnign the complex reports, even
though the origin of the data was Oracle, since the application was
Oracle specific.   It took less time to duplicate the database and run
the query on PostgreSQL than it did to just run it on Oracle.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ivan Voras
Дата:
Сообщение: Query performance with disabled hashjoin and mergejoin
Следующее
От: Mladen Gogala
Дата:
Сообщение: Re: Talking about optimizer, my long dream