15.10.2010 22:29, Tom Lane:
Nikolai Zhubrn-a-zh...@yandex.ru 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
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 unnamed [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
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
On Sat, Oct 16, 2010 at 8:29 AM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
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
16.10.10 19:51, Mladen Gogala написав(ла):
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
On 10/18/2010 3:58 AM, Vitalii Tymchyshyn wrote:
Hello.
Did you vacuum postgresql DB before the count(*). I ask this because
(unless table was created loaded in same transaction) on the first
scan, postgresql has to write hint bits to the whole table. Second scan
may be way faster.
Best
Eric Comeau ecom...@signiant.com writes:
2010-10-16 05:55:52 EDT [6334]: [1-1] LOG: duration: 5572.517 ms
statement: EXECUTE unnamed [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
statement: EXECUTE unnamed [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT
Tom Lane wrote:
My guess would be overstressed disk subsystem. A COMMIT doesn't require
much except fsync'ing the commit WAL record down to disk ...
Doesn't the commit statement also release all the locks held by the
transaction?
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY
Excerpts from Samuel Gendler's message of lun oct 18 03:13:01 -0300 2010:
On Sat, Oct 16, 2010 at 8:29 AM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
Excerpts from Samuel Gendler's message of sáb oct 16 02:35:46 -0300 2010:
An issue with automatically analyzing the entire hierarchy
Mladen Gogala mladen.gog...@vmsinfo.com writes:
Tom Lane wrote:
My guess would be overstressed disk subsystem. A COMMIT doesn't require
much except fsync'ing the commit WAL record down to disk ...
Doesn't the commit statement also release all the locks held by the
transaction?
Yeah, and
On Mon, Oct 18, 2010 at 1:16 AM, AI Rumman rumman...@gmail.com wrote:
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
I have a table with an array column.
I added a GIN index to the array:
CREATE INDEX foo_idx ON t USING GIN (alternatecodes) WHERE
alternatecodes IS NOT NULL;
That's all well and good.
However, some queries started failing and I was able to reproduce the
behavior in psql!
SELECT * FROM t WHERE
Jon Nelson jnelson+pg...@jamponi.net writes:
CREATE INDEX foo_idx ON t USING GIN (alternatecodes) WHERE
alternatecodes IS NOT NULL;
SELECT * FROM t WHERE alternatecodes IS NOT NULL;
ERROR: GIN indexes do not support whole-index scans
Yep, this is a known issue. It's going to take major
8.4.5
I consistently see HashJoin plans that hash the large table, and scan the small
table. This is especially puzzling in some cases where I have 30M rows in the
big table and ~ 100 in the small... shouldn't it hash the small table and scan
the big one?
Here is one case I saw just recently
On Mon, Oct 18, 2010 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jon Nelson jnelson+pg...@jamponi.net writes:
CREATE INDEX foo_idx ON t USING GIN (alternatecodes) WHERE
alternatecodes IS NOT NULL;
SELECT * FROM t WHERE alternatecodes IS NOT NULL;
ERROR: GIN indexes do not support
Scott Carey sc...@richrelevance.com writes:
I consistently see HashJoin plans that hash the large table, and scan
the small table.
Could we see a self-contained test case? And what cost parameters are
you using, especially work_mem?
This is especially puzzling in some cases where I have 30M
16 matches
Mail list logo
