"Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> In this case, I believe the best choice to improve the performance of this
> particular SQL statement is adding the 'set join_collapse_limit = 1;' just
> before the join statement, correct?
That's a mighty blunt instrument. The real problem with yo
Hi,
In this case, I believe the best choice to improve the performance of this
particular SQL statement is adding the 'set join_collapse_limit = 1;' just
before the join statement, correct?
It there anything else we could do to, in this case, make the planner choose
better paths using the default
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think "distinct" just doesn't know about hash aggregates yet. That's partly
> an oversight and partly of a "feature" in that it gives a convenient way to
> write a query which avoids them. I think it's also partly that "distinct" is
> trickier to fix be
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> I notice that I get different plans when I run the
> following two queries that I thought would be
> identical.
>
> select distinct test_col from mytable;
> select test_col from mytable group by test_col;
>
> Any reason why it favors one in one case bu
I notice that I get different plans when I run the
following two queries that I thought would be
identical.
select distinct test_col from mytable;
select test_col from mytable group by test_col;
Any reason why it favors one in one case but not the other?
d=# explain analyze select distinct
It's a 4 processor Intel xeon machine with more than enough ram. The
entire database can fit in memory, and while the CPU is pegged,
nothing is chewing up I/O bandwidth, and nothing is getting swapped
out of RAM.
I'm running Debian stable with only a few tweaks to the kernel's
memory settings. A
On Thursday 02 August 2007 09:02, "Bryan Murphy" <[EMAIL PROTECTED]>
wrote:
> My question: Is there a way I can decrease the priority of a specific
> query, or determine the PID of the process it is running in? I'd like
> to throw together a quick shell script if at all possible, as right
> now
We have a complicated stored procedure that we run frequently. It
pegs one of our postmaster processes at 100% CPU utilization for a few
hours. This has the unfortunate side effect of causing increased
latency for our other queries. We are currently planning a fix, but
because of the complicated
