On Tue, Dec 11, 2012 at 6:03 PM, Craig Ringer wrote:
> On 12/12/2012 06:44 AM, Evgeny Shishkin wrote:
>
>
> On Dec 12, 2012, at 2:41 AM, Niels Kristian Schjødt
> wrote:
>
> Are you using a hardware based raid controller with them?
>
> Yes, of course. Hardware raid with cache and bbu is a must. Yo
AI Rumman wrote:
> The ENTITY table has 2164493 rows with data as follows:
>
> type | count
> ---+
> Contacts | 327352
> Candidate | 34668
> Emailst | 33604
> Calendar | 493956
> Contacts Image | 7
> PriceBooks | 2
> Notes Attachment | 17
> SalesOrder | 6
> A
On Fri, Dec 14, 2012 at 3:34 PM, Kevin Grittner wrote:
> Claudio Freire wrote:
>
> > Selectivity is decided based on the number of distinct values on
> > both sides, and the table's name "entity" makes me think it's a
> > table that is reused for several things. That could be a problem,
> > since
Claudio Freire wrote:
> Selectivity is decided based on the number of distinct values on
> both sides, and the table's name "entity" makes me think it's a
> table that is reused for several things. That could be a problem,
> since that inflates distinct values, feeding misinformation to
> the plan
On Fri, Dec 14, 2012 at 5:25 PM, AI Rumman wrote:
> Are you suggesting to make different table for Contacts, Candidate etc.
Yes
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performan
Yes, I do have a column in entity table like
setype where the values are 'Contacts', 'Candidate' etc.
I have an index on it also.
Are you suggesting to make different table for Contacts, Candidate etc.
On Fri, Dec 14, 2012 at 3:10 PM, Claudio Freire wrote:
> On Fri, Dec 14, 2012 at 4:22 PM, Tom L
On 12/14/2012 02:56 PM, Tom Lane wrote:
Andrew Dunstan writes:
One of my clients has an odd problem. Every so often a backend will
suddenly become very slow. The odd thing is that once this has happened
it remains slowed down, for all subsequent queries. Zone reclaim is off.
There is no IO or C
On Fri, Dec 14, 2012 at 4:22 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> AI Rumman wrote:
>>> Does FK Constraint help to improve performance? Or it is only
>>> for maintaining data integrity?
>
>> I'm not aware of any situation where adding a foreign key
>> constraint would improve performa
Andrew Dunstan writes:
> One of my clients has an odd problem. Every so often a backend will
> suddenly become very slow. The odd thing is that once this has happened
> it remains slowed down, for all subsequent queries. Zone reclaim is off.
> There is no IO or CPU spike, no checkpoint issues o
So I am going to change
join_collapse_limit
and
from_collapse_limit
to 20.
Do I need to set geqo_threshold to greater than 20. Now it is 12 ( default).
And could you let me know why geqo_optimizer is not working good in this
case?
On Fri, Dec 14, 2012 at 2:22 PM, Tom Lane wrote:
> "Kevin Gri
"Kevin Grittner" writes:
> AI Rumman wrote:
>> Does FK Constraint help to improve performance? Or it is only
>> for maintaining data integrity?
> I'm not aware of any situation where adding a foreign key
> constraint would improve performance.
There's been talk of teaching the planner to use the
AI Rumman wrote:
> Claudio Freire wrote:
>> I think it's more likely a missing FK constraint.
> Does FK Constraint help to improve performance? Or it is only
> for maintaining data integrity?
I'm not aware of any situation where adding a foreign key
constraint would improve performance.
-Kevin
On Fri, Dec 14, 2012 at 4:01 PM, AI Rumman wrote:
> Does FK Constraint help to improve performance? Or it is only for
> maintaining data integrity?
I'm not entirely sure it's taken into account, I think it is, but a FK
would tell the planner that every non-null value will produce a row.
It seems
Does FK Constraint help to improve performance? Or it is only
for maintaining data integrity?
On Thu, Dec 13, 2012 at 7:38 PM, Claudio Freire wrote:
> On Thu, Dec 13, 2012 at 8:50 PM, Evgeny Shishkin
> wrote:
> >>> OP joins 8 tables, and i suppose join collapse limit is set to default
> 8. I tho
One of my clients has an odd problem. Every so often a backend will
suddenly become very slow. The odd thing is that once this has happened
it remains slowed down, for all subsequent queries. Zone reclaim is off.
There is no IO or CPU spike, no checkpoint issues or stats timeouts, no
other symp
Huan Ruan wrote:
> Kevin Grittner wrote:
>> With a low cache hit rate, that would generally be when the number
>> of lookups into the table exceeds about 10% of the table's rows.
>
> So far, my main performance issue comes down to this pattern where
> Postgres chooses hash join that's slower than
16 matches
Mail list logo
