On Sat, Oct 16, 2010 at 8:29 AM, Alvaro Herrera
wrote:
> Excerpts from Samuel Gendler's message of sáb oct 16 02:35:46 -0300 2010:
>
> > An issue with automatically analyzing the entire hierarchy is 'abstract'
> > table definitions. I've got a set of tables for storing the same data at
> > differ
There was some doubt as for the speed of doing the select count(*) in
PostgreSQL and Oracle.
To that end, I copied the most part of the Oracle table I used before to
Postgres. Although the copy
wasn't complete, the resulting table is already significantly larger
than the table it was copied from
We currently have
log_min_duration_statement = 5000
and are seeing statements like the following logged
2010-10-16 05:55:52 EDT [6334]: [1-1] LOG: duration: 5572.517 ms
statement: EXECUTE [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
statement: EXE
15.10.2010 22:29, Tom Lane:
Nikolai Zhubr writes:
So, "in (1, 2)" condition is not in Index Cond anymore! Why is that? How
can I push it back?
It thinks the indexscan condition is sufficiently selective already.
An = ANY condition like that will force multiple index searches,
one for each of
At present for reporting I use following types of query:
select crm.*, crm_cnt.cnt
from crm,
(select count(*) as cnt from crm) crm_cnt;
Here count query is used to find the total number of records.
Same FROM clause is copied in both the part of the query.
Is there any other good alternative way to
