Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread bricklen
On Fri, Sep 30, 2011 at 2:12 PM, Merlin Moncure wrote: >> FWIW, speaking as somebody who has no need of this function, "array_xor" is >> a pretty clear name that indicates what's going to happen. > > +1 on this -- was going to suggest until you beat me to it.  I also > for the record really think

Re: [PERFORM] PostgreSQL-9.0 Monitoring System to improve performance

2011-09-30 Thread Bobby Dewitt
EnterpriseDB now has Postgres Enterprise Manager (http://enterprisedb.com/products-services-training/products/postgres-enter prise-manager) that has some of the information that is being asked for. It has a hot table analysis report that shows the number of scans, rows read, etc. Since much of the

Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread Merlin Moncure
On Fri, Sep 30, 2011 at 3:15 PM, Ben Chobot wrote: > > On Sep 30, 2011, at 12:07 PM, bricklen wrote: > >> I've been informed that this type of operation is called "symmetric >> difference"[1], and can be represented by A ∆ B.  A couple of >> alternative names were proposed, "array_symmetric_differ

Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread Ben Chobot
On Sep 30, 2011, at 12:07 PM, bricklen wrote: > I've been informed that this type of operation is called "symmetric > difference"[1], and can be represented by A ∆ B. A couple of > alternative names were proposed, "array_symmetric_difference" and > "array_xor". > Does anyone have a preference fo

Re: [PERFORM] Shortcutting too-large offsets?

2011-09-30 Thread Tom Lane
Josh Berkus writes: >> In principle, yeah, we could make it do that, but it seems like a likely >> source of maintenance headaches. This example is not exactly compelling >> enough to make me want to do it. Large OFFSETs are always going to be >> problematic from a performance standpoint, and th

Re: [PERFORM] Shortcutting too-large offsets?

2011-09-30 Thread Josh Berkus
Tom, > In principle, yeah, we could make it do that, but it seems like a likely > source of maintenance headaches. This example is not exactly compelling > enough to make me want to do it. Large OFFSETs are always going to be > problematic from a performance standpoint, and the fact that we coul

Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread bricklen
On Fri, Sep 30, 2011 at 5:23 AM, Vitalii Tymchyshyn wrote: > Since you are using except and not except all, you are not looking at arrays > with duplicates. > For this case next function what the fastest for me: > > create or replace function array_except2(anyarray,anyarray) returns > anyarray as

Re: [PERFORM] the number of child tables --table partitioning

2011-09-30 Thread alexandre - aldeia digital
Em 30-09-2011 14:01, Merlin Moncure escreveu: 2011/9/29 Ondrej Ivanič: Hi, On 30 September 2011 01:08, Kevin Grittner wrote: Is there a suggested number of child tables for table partitioning, Generally, don't go over about 100 partitions per table. Having 365 partitions per table is fine..

Re: [PERFORM] the number of child tables --table partitioning

2011-09-30 Thread Merlin Moncure
2011/9/29 Ondrej Ivanič : > Hi, > > On 30 September 2011 01:08, Kevin Grittner > wrote: >>> Is there a suggested number of child tables for table >>> partitioning, >> >> Generally, don't go over about 100 partitions per table. > > Having 365 partitions per table is fine... yeah -- the system was

Re: [PERFORM] Shortcutting too-large offsets?

2011-09-30 Thread pasman pasmański
It may be difficult, i think. When unsorted recordset is stored in temp table, number of records may be saved and used. Otherwise it is unknown. 2011/9/30, Josh Berkus : > All, > > Here's a case which it seems like we ought to be able to optimize for: > > datamart-# ORDER BY txn_timestamp DESC > d

Re: [PERFORM] Shortcutting too-large offsets?

2011-09-30 Thread Tom Lane
Josh Berkus writes: > Here's a case which it seems like we ought to be able to optimize for: > [ offset skips all the output of a sort node ] > Is there some non-obvious reason which would make this kind of > optimization difficult? Doesn't the executor know at that point how > many rows it has?

Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread bricklen
On Fri, Sep 30, 2011 at 5:23 AM, Vitalii Tymchyshyn wrote: > Since you are using except and not except all, you are not looking at arrays > with duplicates. > For this case next function what the fastest for me: > > create or replace function array_except2(anyarray,anyarray) returns > anyarray as

Re: [PERFORM] array_except -- Find elements that are not common to both arrays

2011-09-30 Thread Vitalii Tymchyshyn
Since you are using except and not except all, you are not looking at arrays with duplicates. For this case next function what the fastest for me: create or replace function array_except2(anyarray,anyarray) returns anyarray as $$ select ARRAY( ( select r.elements from( (select 1,unne

Re: [PERFORM] PostgreSQL-9.0 Monitoring System to improve performance

2011-09-30 Thread Gregg Jaskiewicz
Looks like this is generally an area that can be targeted by some businesses. Or an open source enthusiast. One centre that captures all the information and produces a report based on it would be a great thing. Especially in cases like mine, where I have tens of postgresql installations on differen

Re: [PERFORM] : Create table taking time

2011-09-30 Thread Venkat Balaji
CPU load was hitting 100% constantly with high IOs. We tuned some queries to decrease the CPU usage and everything is normal now. Thanks VB On Fri, Sep 30, 2011 at 10:52 AM, Venkat Balaji wrote: > I did not calculate the IO behavior of the server. > > What i noticed for the logs is that, the ch

Re: [PERFORM] PostgreSQL-9.0 Monitoring System to improve performance

2011-09-30 Thread Venkat Balaji
Hi Tomas, I will let you know about "check_postgres.pl". We will explore "pgmonitor" as well. The other tool we are working on is "pgwatch", we found this very useful. Thanks VB On Wed, Sep 28, 2011 at 5:44 PM, Tomas Vondra wrote: > On 28 Září 2011, 9:05, Greg Smith wrote: > > Venkat Balaji

Re: [PERFORM] PostgreSQL-9.0 Monitoring System to improve performance

2011-09-30 Thread Venkat Balaji
Thanks Greg ! Sorry, I should have put it the other way. Actually, I am looking for any tool (if exists) which gets me the following information with one installation or so. Please see my replies below. Thanks VB On Wed, Sep 28, 2011 at 12:35 PM, Greg Smith wrote: > Venkat Balaji wrote: > >>