Robert Haas writes:
> On Thu, Sep 24, 2009 at 8:25 PM, Josh Berkus wrote:
>> You can't "turn off" sequential scans. You can only make the planner
>> less likely to choose them. But if there's no way to get the data you
>> need other than a seqscan, it's still going to do one.
> And that's not
On Thu, Sep 24, 2009 at 8:22 AM, Jared Beck wrote:
> Should we try to improve statistics collection for that column
> (variableid) by using ALTER TABLE ... ALTER COLUMN ... SET STATISTICS?
It's worth a try, but I'm not sure it's going to help much. The LIKE
condition is hard for the planner to e
2009/9/25 Jeff Janes :
> 2009/9/22 Grzegorz Jaśkiewicz :
>> On Tue, Sep 22, 2009 at 1:46 PM, Alan McKay wrote:
Best practice to avoid that, is to bump the work_mem temporarily
before the query, and than lower it again, lowers the chance of memory
exhaustion.
>>>
>>> Interesting - I
On Thu, Sep 24, 2009 at 8:25 PM, Josh Berkus wrote:
> You can't "turn off" sequential scans. You can only make the planner
> less likely to choose them. But if there's no way to get the data you
> need other than a seqscan, it's still going to do one.
And that's not a bad thing. For a very sma
Hello Tom,
The query was logically ok. The main problem was that the VIEW had an
ORDER BY clause where cost went up to very high. Indices and unique
constraints were minor optimizations.
Conclusio: Don't create ORDER BY in VIEW unless really necessary
Ciao,
Gerhard
--
http://www.wiesinger.c
