Re: Query performance with disabled hashjoin and mergejoin

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Query performance with disabled hashjoin and mergejoin
Дата
Msg-id 4D4C10EA.2080901@2ndquadrant.com
обсуждение исходный текст
Ответ на Query performance with disabled hashjoin and mergejoin  (Ivan Voras <ivoras@freebsd.org>)
Ответы Re: Query performance with disabled hashjoin and mergejoin  (Ivan Voras <ivoras@freebsd.org>)
Re: Query performance with disabled hashjoin and mergejoin  (Ivan Voras <ivoras@gmail.com>)
Список pgsql-performance
Ivan Voras wrote:
> The "vanilla" plan, with default settings is:

Pause here for a second:  why default settings?  A default PostgreSQL
configuration is suitable for systems with about 128MB of RAM.  Since
you say you have "good enough hardware", I'm assuming you have a bit
more than that.  The first things to try here are the list at
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server ; your bad
query here looks like it might benefit from a large increase to
effective_cache_size, and possibly an increase to work_mem as well.
Your "bad" plan here is doing a lot of sequential scans instead of
indexed lookups, which makes me wonder if the change in join types
you're forcing isn't fixing that part as a coincidence.

Note that the estimated number of rows coming out of each form of plan
is off by a factor of about 200X, so it's not that the other plan type
is better estimating anything.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


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

Предыдущее
От: Vitalii Tymchyshyn
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: felix
Дата:
Сообщение: Really really slow select count(*)