Hello,
A simple query is executing much slower than expected. When looking at
the query plan, I see a bitmap index scan on a partial index that does
not have any associated index condition. How could that happen?
The query is:
select id from test_run_results where test_run_id = 12902 and status
On Fri, Apr 25, 2008 at 12:13 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jimmy Choi [EMAIL PROTECTED] writes:
A simple query is executing much slower than expected. When looking at
the query plan, I see a bitmap index scan on a partial index that does
not have any associated index condition
Hello,
Does running cluster remove the need to run vacuum?
I get a feeling that since cluster is already physically reordering
the rows, it may as well remove the dead rows... no?
My second question is, if vacuum is still needed, does it matter
whether I run vacuum first or cluster first?
?
Here's our current weekly db maintenance routine:
1. vacuum full
2. cluster
3. reindex
4. analyze
Thanks,
Jimmy Choi
Confidentiality Notice. This message may contain information that is
confidential or otherwise protected from disclosure.
If you are not the intended recipient, you are hereby
Presumably, even if CLUSTER does reindexing internally, it only does
that for the index used for clustering. Since REINDEX includes all
indices, CLUSTER cannot truly replace REINDEX. Correct?
Jimmy
On Wed, Apr 16, 2008 at 12:06 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Craig Ringer escribió:
I'm looking for general guideline on the use of temporary tables.
I would like to use temporary table as a caching mechanism to speed up
queries within the same session. Specifically, a temporary table is
created to store a subset of data from a possibly large table, and
subsequent queries select
Suppose I have the following table named metrics:
metric_type | val
+-
0 | 1
0 | 1
1 | 0
1 | 3
Now suppose I run the following simple query:
select
metric_type,
case metric_type
when 0 then
sum (1 / val)
Suppose I have the following table named metrics:
metric_type | val
+-
0 | 1
0 | 1
1 | 0
1 | 3
Now suppose I run the following simple query:
select
metric_type,
case metric_type
when 0 then
sum (1 / val)
when 1
then
min (val)
end as result
from metrics
group by metric_type
Thanks!
On 10/3/07, Rodrigo De León [EMAIL PROTECTED] wrote:
On 10/3/07, Jimmy Choi [EMAIL PROTECTED] wrote:
I expect to get the following result set:
metric_type | result
+---
0 | 2
1
Have you tried clustering tables based on the most-frequently used
indexes to improve locality?
http://www.postgresql.org/docs/8.2/static/sql-cluster.html
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Moran
Sent: Wednesday, September 26, 2007
Say I have the following parameterized query in a function:
select * from foo where ($1 = -1 or
foo.status = $1) and ()
where the () part consists of more parameterized
conditions similar to the first one.
Suppose that at runtime, $1 is supplied a value of -1, does
the foo.status
Hello,
From Section 11.4 of the Postgres 8.1 documentation, a new optimization
is shipped in the latest release.
... a query like WHERE x = 42 OR x = 47 OR x = 53 OR x = 99 could be
broken down into four separate scans of an index on x, each scan using
one of the query clauses. The results of
12 matches
Mail list logo
