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
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
On Apr 30, 2011, at 10:21 PM, Tom Lane t...@sss.pgh.pa.us 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
-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 no
Pavel Stehule pavel.steh...@gmail.com 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
On Apr 30, 2011, at 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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,
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane t...@sss.pgh.pa.us 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
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lanet...@sss.pgh.pa.us 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
Mark Kirkwood mark.kirkw...@catalyst.net.nz writes:
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lanet...@sss.pgh.pa.us 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
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
---
11 matches
Mail list logo
