> mergejoinscansel doesn't currently try to fix up the histogram bounds
> by
> consulting indexes. At the time I was afraid of the costs of doing
> that, and I still am; but it would be a way to address this issue.
Oh? Hmmm. I have a ready-made test case for the benefit case on this.
However
> mergejoinscansel doesn't currently try to fix up the histogram bounds by
> consulting indexes. At the time I was afraid of the costs of doing
> that, and I still am; but it would be a way to address this issue.
>
Another cheaper but less accurate way to deal with this is to note
that we are try
On 3/23/11 2:08 PM, "Claudio Freire" wrote:
>On Wed, Mar 23, 2011 at 6:00 PM, Tom Lane wrote:
>> Claudio Freire writes:
>>> In my head, safer = better worst-case performance.
>>
>> If the planner starts operating on the basis of worst case rather than
>> expected-case performance, the complai
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
25.03.11 16:12, Tom Lane написав(ла):
Vitalii Tymchyshyn writes:
Why so? I simply change cost estimation functions. This won't change
number of pathes.
If you have multiple figures of merit, that means you have to keep more
paths, with consequent slowdown when it comes to choosing which path
If it's a HP box you can also turn this off via the bios via your RBSU:
Starting with HP ProLiant G6 servers that utilize Intel® Xeon® processors,
setting the HP Power Profile
Option in RBSU to Maximum Performance Mode sets these recommended additional
low-latency options
for minimum BIOS late
Josh Berkus writes:
>> If the planner starts operating on the basis of worst case rather than
>> expected-case performance, the complaints will be far more numerous than
>> they are today.
> Yeah, I don't think that's the way to go. The other thought I had was
> to accumulate a "risk" stat the s
Vitalii Tymchyshyn writes:
> 24.03.11 20:41, Merlin Moncure ÎÁÐÉÓÁ×(ÌÁ):
>> ISTM if you add statistics miss and 'risk margin' to the things the
>> planner would have to consider while generating a plan, you are
>> greatly increasing the number of plan paths that would have to be
>> considered for
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
I suspect that, since the matched hid's probably aren't sequential,
many of those ~500 product_price_offer_history rows will be far apart
on disk.
OMG I was a fool! I'll CLUSTER on a different index and it will be fast,
I'm sure.
Thanks!
L
--
Sent via pgsql-performance mailing list (pgs
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
24.03.11 20:41, Merlin Moncure написав(ла):
2011/3/24 Віталій Тимчишин:
This can se GUC-controllable. Like plan_safety=0..1 with low default value.
This can influence costs of plans where cost changes dramatically with small
table changes and/or statistics is uncertain. Also this can be used as
>> 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
2011/3/25 DM :
> gettimeofday() on my new box is slow, after further research we found that,
> when we set ACPI=Off, we got a good clock performance even the explain
> analyze gave approximately gave the right values, but the hyperthreading is
> off.
Disabling ACPI also disables most CPU power man
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
19 matches
Mail list logo
