From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | phb07 <phb07(at)apra(dot)asso(dot)fr> |
Cc: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com>, damien hostin <damien(dot)hostin(at)axege(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow query with planner row strange estimation |
Date: | 2010-07-22 18:08:45 |
Message-ID: | AANLkTinZTtR7aAM+98z+TpWT+bO63A0DCTZNETSPsR1J@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Jul 12, 2010 at 4:33 PM, phb07 <phb07(at)apra(dot)asso(dot)fr> wrote:
>
> Dimitri a écrit :
>>
>> It's probably one of the cases when having HINTS in PostgreSQL may be
>> very helpful..
>>
>> SELECT /*+ enable_nestloop=off */ ... FROM ...
>>
>> will just fix this query without impacting other queries and without
>> adding any additional instructions into the application code..
>>
>> So, why there is a such resistance to implement hints withing SQL
>> queries in PG?..
>>
>
> +1.
> Another typical case when it would be helpful is with setting the
> cursor_tuple_fraction GUC variable for a specific statement, without being
> obliged to issue 2 SET statements, one before the SELECT and the other
> after.
We've previously discussed adding a command something like:
LET (variable = value, variable = value, ...) command
...which would set those variables just for that one command. But
honestly I'm not sure how much it'll help with query planner problems.
Disabling nestloops altogether, even for one particular query, is
often going to be a sledgehammer where you need a scalpel. But then
again, a sledgehammer is better than no hammer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-07-22 18:33:43 | Re: Pooling in Core WAS: Need help in performance tuning. |
Previous Message | Craig James | 2010-07-22 16:57:06 | Re: Using more tha one index per table |