On 01/05/11 21:16, Joshua Berkus wrote:
> Speaking of which, what happened to replacing GEQO with Simulated Annealing?
> Where did that project go?
It stayed on github (https://github.com/wulczer/saio) and stagnated a
bit after I got my degree. It's on the top of my list of things to pick
up aft
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Joshua Berkus wrote:
> I'm not comfortable with increasing the default, yet. While folks on
> dedicated good hardware can handle a collapse of 10-12 joins, a lot
> of people are running PostgreSQL on VMs these days whose real CPU
> power is
On Apr 30, 2011, at 10:21 PM, Tom Lane wrote:
> It also occurs to me to wonder if we could adjust the limit on-the-fly
> based on noticing whether or not the query is prone to worst-case
> behavior, ie how dense is the join connection graph.
I've had this thought - or a similar one - before also.
Pavel,
> Actually we had to solve a issue with slow SELECT. The problem was in
> low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
> value. I checked some complex query, and planner needed about 200ms
> for JOIN_COLLAPSE_LIMIT = 16. So some around 12 can be well.
I'm not comfo
Hello
a slow query is just simple
like
SELECT FROM a
LEFT JOIN b ON ..
LEFT JOIN c ON ..
LEFT JOIN d ON ..
LEFT JOIN e ON ..
WHERE e.x = number
a slow query plan
explain analyze select * from v_vypis_parcel_puvodni where par_id = 1396907206
---
Mark Kirkwood writes:
> On 01/05/11 11:53, Greg Stark wrote:
>> On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane wrote:
>>> - it would require a query in which
>>> every relation is linked to every other relation by a join clause.
>>> But that *can* happen (remember that clauses generated by transitive
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane wrote:
- it would require a query in which
every relation is linked to every other relation by a join clause.
But that *can* happen (remember that clauses generated by transitive
equality do count).
It sounds like y
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane wrote:
> - it would require a query in which
> every relation is linked to every other relation by a join clause.
> But that *can* happen (remember that clauses generated by transitive
> equality do count).
It sounds like you're describing precisely a "st
Robert Haas writes:
> I seem to remember that I was the last one to suggest raising these limits
> and someone demonstrated rather convincingly that for certain classes of
> queries that would cause really big problems.
You proposed removing the collapse limits altogether, but that crashed
and
On Apr 30, 2011, at 7:38 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> Actually we had to solve a issue with slow SELECT. The problem was in
>> low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
>> value. I checked some complex query, and planner needed about 200ms
>> for JOIN_
Pavel Stehule writes:
> Actually we had to solve a issue with slow SELECT. The problem was in
> low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
> value. I checked some complex query, and planner needed about 200ms
> for JOIN_COLLAPSE_LIMIT = 16. So some around 12 can be well.
Hello
Actually we had to solve a issue with slow SELECT. The problem was in
low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
value. I checked some complex query, and planner needed about 200ms
for JOIN_COLLAPSE_LIMIT = 16. So some around 12 can be well.
Regards
Pavel Stehule
12 matches
Mail list logo
