[PERFORM] Indexing an array of two separate columns

2017-09-15 Thread Jeremy Finzel
I have a user who is trying to match overlapping duplicate phone info but for different customer_ids. The intended conditional could be expressed: IF the intersection of the sets {c.main_phone, c.secondary_phone} and {c1.main_phone, c1.secondary_phone} is not empty THEN join EXCEPT where the inter

Re: [PERFORM] Odd sudden performance degradation related to temp object churn

2017-08-18 Thread Jeremy Finzel
On Tue, Aug 15, 2017 at 12:07 PM, Scott Marlowe wrote: > So do iostat or iotop show you if / where your disks are working > hardest? Or is this CPU overhead that's killing performance? > Sorry for the delayed reply. I took a look in more detail at the query plans from our problem query during t

Re: [PERFORM] Odd sudden performance degradation related to temp object churn

2017-08-15 Thread Jeremy Finzel
> > > Not so. > > > > This system has no defined temp_tablespace however spillage due to > > sorting/hashing that exceeds work_mem goes to base/pgsql_tmp which we > > have symlinked out to a local SSD drive. > > Which is also where temp tables are created. > This isn't true, at least in our enviro

Re: [PERFORM] Odd sudden performance degradation related to temp object churn

2017-08-14 Thread Jeremy Finzel
On Mon, Aug 14, 2017 at 3:01 PM, Scott Marlowe wrote: > On Mon, Aug 14, 2017 at 1:53 PM, Jeremy Finzel wrote: > > This particular db is on 9.3.15. Recently we had a serious performance > > degradation related to a batch job that creates 4-5 temp tables and 5 > > indexes.

[PERFORM] Odd sudden performance degradation related to temp object churn

2017-08-14 Thread Jeremy Finzel
This particular db is on 9.3.15. Recently we had a serious performance degradation related to a batch job that creates 4-5 temp tables and 5 indexes. It is a really badly written job but what really confuses us is that this job has been running for years with no issue remotely approaching this on

Re: [PERFORM] index of only not null, use function index?

2017-06-08 Thread Jeremy Finzel
Normally, I find that in these situations, it makes sense to index the primary key of the table WHERE col is not null, because it will usually cover the largest number of cases, and is much better than a two-value boolean index, for example. On Thu, Jun 8, 2017 at 9:58 AM, Tom Lane wrote: > Merl

[PERFORM] Impact of track_activity_query_size on high traffic OLTP system

2017-04-13 Thread Jeremy Finzel
I have found some examples of people tweaking this parameter track_activity_query_size to various setting such as 4000, 1, 15000, but little discussion as to performance impact on memory usage. What I don't have a good sense of is how significant this would be for a high traffic system with rap