| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Benedikt Grundmann <bgrundmann(at)janestreet(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: random_page_cost vs seq_page_cost |
| Date: | 2012-01-05 14:32:30 |
| Message-ID: | CA+TgmoY4DBtqTX+ee8CMA55aoY169EX2wdXRSAv6twvdwg4TxQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
<bgrundmann(at)janestreet(dot)com> wrote:
> We are experiencing a big performance regression in some queries.
> In those cases the planner seems to choose a nested loop index
> scan instead of hashing the index once and then joining.
I think you probably need to post EXPLAIN ANALYZE output from the
actual queries to get useful advice, probably to pgsql-performance,
rather than here.
It's hard to believe that enable_nestloop=off is doing anything other
than masking whatever the real problem is, but it's hard to tell what
that problem is based on the information provided.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Benedikt Grundmann | 2012-01-05 14:34:27 | Re: random_page_cost vs seq_page_cost |
| Previous Message | Robert Haas | 2012-01-05 14:28:30 | Re: FATAL: bogus data in lock file "postmaster.pid": "" |