"Dave North" writes:
> The outstanding question here is why does the explain analyze take
> (quite a bit) longer than just executing the query?
EXPLAIN ANALYZE has nontrivial measurement overhead, especially on
platforms with slow gettimeofday(). Old/cheap PC hardware, in particular,
tends to su
ave
> -Original Message-
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf
> Of Greg Stark
> Sent: June 25, 2009 5:30 PM
> To: Tom Lane
> Cc: Dave North; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Nested Loop "Killer" on 8.1
>
&g
On Thu, Jun 25, 2009 at 10:05 PM, Tom Lane wrote:
>
> Uh, it appears to me the string *does* contain _ characters; perhaps the
> OP has neglected to escape those?
Sigh. Indeed.
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.o
Greg Stark writes:
> On Wed, Jun 24, 2009 at 1:43 PM, Dave North wrote:
> Why use "like" for a constant string with no % or _ characters? If you
> used = the planner might be able to come up with a better estimate.
Uh, it appears to me the string *does* contain _ characters; perhaps the
OP has ne
On 06/25/2009 04:36 PM, Greg Stark wrote:
AND
web_user_property_directory_outbox.prop_key like
'location_node_directory_outbox'
Why use "like" for a constant string with no % or _ characters? If you
used = the planner might be able to come up with a better estimate
Any reason why "l
On Wed, Jun 24, 2009 at 1:43 PM, Dave North wrote:
> Essentially, we're seeing a query plan that is taking 95 secs with a nested
> loop execution plan and 1 sec with a merge join plan. We've tried
> increasing the default_statistics_target to 1000 and re-analyzed but the
> same query plan is retu
Dave,
Is there further optimizations we can do to change the plan?
Is this perhaps addressed in a later release?
Given the left joins, a later release might help; I know we did a lot to
improve left join plans in 8.3. It would be worth testing if you can
test an upgrade easily.
--
Josh Be
Morning all,
A colleague here tried to post this yesterday but it was stalled for
some reason. Anyway, here's what we're seeing which hopefully someone
has some pointers for.
Essentially, we're seeing a query plan that is taking 95 secs with a
nested loop execution plan and 1 sec with a merg
