On 03/25/2011 12:49 PM, Maciek Sakrejda wrote:
Indexes aren't a magical performance fairy dust.
One day I intend to use this line for the title of a presentation
slide. Maybe the title of the whole talk.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Trai
To expand on what Shaun said:
> But your fundamental problem is that you're joining two
> giant tables with no clause to limit the result set. If you were only
> getting back 10,000 rows, or even a million rows, your query could execute
> in a fraction of the time. But joining every row in both ta
On 03/25/2011 04:07 AM, Chetan Suttraway wrote:
The ideas is to have maximum filtering occuring on leading column of index.
the first plan with only the predicates on clause_id is returning
379772050555842 rows whereas
in the second plan with doc_id predicates is returning only 20954686217.
So
Chetan Suttraway wrote:
On Fri, Mar 25, 2011 at 2:25 PM, Adarsh Sharma
mailto:adarsh.sha...@orkash.com>> wrote:
Could you please post output of below queries:
explain select c.clause, s.* from clause2 c, svo2 s where
c.clause_id=s.clause_id;
explain select c.clause, s.* fro
>> Merge Join (cost=5673831.05..34033959.87 rows=167324179 width=2053)
>> Merge Cond: ((s.clause_id = c.clause_id) AND (s.doc_id =
>> c.source_id) AND (s.sentence_id = c.sentence_id))
>> -> Index Scan using idx_svo2 on svo2 s (cost=0.00..24489343.65
>> rows=27471560 width=1
On Fri, Mar 25, 2011 at 2:25 PM, Adarsh Sharma wrote:
>
> Could you please post output of below queries:
> explain select c.clause, s.* from clause2 c, svo2 s where
> c.clause_id=s.clause_id;
> explain select c.clause, s.* from clause2 c, svo2 s where
> s.doc_id=c.source_id;
> explain select c.cla
Could you please post output of below queries:
explain select c.clause, s.* from clause2 c, svo2 s where
c.clause_id=s.clause_id;
explain select c.clause, s.* from clause2 c, svo2 s where
s.doc_id=c.source_id;
explain select c.clause, s.* from clause2 c, svo2 s where
c.sentence_id=s.sentence
On Fri, Mar 25, 2011 at 12:39 PM, Adarsh Sharma wrote:
> Chetan Suttraway wrote:
>
>
>
> On Fri, Mar 25, 2011 at 12:05 PM, Adarsh Sharma
> wrote:
>
>> Dear all,
>>
>> Today I got to run a query internally from my application by more than 10
>> connections.
>>
>> But The query performed very badl
Adarsh Sharma, 25.03.2011 07:51:
Thanks Andreas, I was about print the output but it takes too much time.
Below is the output of explain analyze command :
pdc_uima=# explain analyze select c.clause, s.* from clause2 c, svo2 s where
c.clause_id=s.clause_id and s.doc_id=c.source_id and c.
pdc_ui
Chetan Suttraway wrote:
On Fri, Mar 25, 2011 at 12:05 PM, Adarsh Sharma
mailto:adarsh.sha...@orkash.com>> wrote:
Dear all,
Today I got to run a query internally from my application by more
than 10 connections.
But The query performed very badly. A the data size of tables ar
On Fri, Mar 25, 2011 at 12:05 PM, Adarsh Sharma wrote:
> Dear all,
>
> Today I got to run a query internally from my application by more than 10
> connections.
>
> But The query performed very badly. A the data size of tables are as :
>
> pdc_uima=# select pg_size_pretty(pg_total_relation_size('c
Thanks Andreas, I was about print the output but it takes too much time.
Below is the output of explain analyze command :
pdc_uima=# explain analyze select c.clause, s.* from clause2 c, svo2 s
where c.clause_id=s.clause_id and s.doc_id=c.source_id and c.
pdc_uima-# sentence_id=s.sentence_id ;
Adarsh Sharma wrote:
> Dear all,
>
> Today I got to run a query internally from my application by more than
> 10 connections.
>
> But The query performed very badly. A the data size of tables are as :
>
> pdc_uima=# select pg_size_pretty(pg_total_relation_size('clause2'));
> pg_size_pretty
> -
Dear all,
Today I got to run a query internally from my application by more than
10 connections.
But The query performed very badly. A the data size of tables are as :
pdc_uima=# select pg_size_pretty(pg_total_relation_size('clause2'));
pg_size_pretty
5858 MB
(1 row)
pdc_ui
14 matches
Mail list logo
