Scott Carey 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 rows in the big
> ta
On Mon, Oct 18, 2010 at 6:01 PM, Tom Lane wrote:
> Jon Nelson 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
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
Jon Nelson 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 surgery on GIN to
fix it,
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 al
On Mon, Oct 18, 2010 at 1:16 AM, AI Rumman 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 copied in both the
Mladen Gogala 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 there's a nontriv
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
> 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
> > > 'abstra
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, N
Eric Comeau writes:
> 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: EXECUTE [PREPARE: COMMIT]
> 2010-10-16 06:06:24 EDT [20740]: [13-1] LOG: duratio
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 rega
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 significant
12 matches
Mail list logo
