Re: [PERFORM] Correcting Hash Join Estimates

On Apr 4, 2005, at 12:54 AM, Tom Lane wrote: [EMAIL PROTECTED] writes: I'm trying to optimize a query and the EXPLAIN ANALYZE (see link below) shows that some hash join row estimates are wrong by a factor of 2-3, and upwards of 7-8. I doubt that improving those estimates would lead to markedly bet

[PERFORM] Correcting Hash Join Estimates

Hello! I posted a similar question to this one about a month ago; but, for some reason, it never seemed to be broadcast eventhough it ended up in the archives. So, since I'm still struggling with this, I thought I'd repost... I'm trying to optimize a query and the EXPLAIN ANALYZE (see link below

[PERFORM] Join method influences scan method?

This apparently didn't go through the first time; so, I'm reposting... - Hello! First off, I'm running 8.0.1 on Win2000 Server. Vacuum analyze is done every night. Query cost parameters are standard, I've only

[PERFORM] Query Optimization - Hash Join estimate off?

Hello!   First off, I'm a real newbie at trying to read the output of explain analyze.   I have several similar queries in my application that I've got incorporated into views.  When they run sub 300ms, the users don't seem to mind.  However, one of them (query is below along with some relevant tab

Re: [PERFORM] [ SOLVED ] select count(*) very slow on an already

On Apr 15, 2004, at 12:44 PM, Richard Huxton wrote: On Thursday 15 April 2004 17:19, Rajesh Kumar Mallah wrote: Bill Moran wrote: BTW is there any way to disable checks and triggers on a table temporarily while loading data (is updating reltriggers in pg_class safe?) You can take a look at pg_re

Re: [PERFORM] tsearch query plan

On Apr 8, 2004, at 6:33 PM, Josh Berkus wrote: Mark, I've got one question about query planning. Is it understandable to have the query plan estimation be off by a couple of orders of magnitude? Or, is it the fact that the cost estimation is small to begin with that the error between the actual

[PERFORM] tsearch query plan

Hello, I've just started using the tsearch2 system. I'm VERY impressed by the speed. I've got one question about query planning. Is it understandable to have the query plan estimation be off by a couple of orders of magnitude? Or, is it the fact that the cost estimation is small to beg

Re: [PERFORM] postgres eating CPU on HP9000

On Mar 29, 2004, at 9:36 AM, Tom Lane wrote: "Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes: Also do you run VACUUM ANALYZE as a superuser, or as a regular user? As a regular user (database owner). Is thery any difference when vacuuming as a super user? That's your problem. A regular u