[PERFORM] Slow concurrent processing

Hi all, We have one table with list of "records for processing"... We loop trough that table and call one long runing function: do_the_math_for_record(record_id) which use different tables for select related rows for input record_id, do some calculations and insert results in two tables... an

Re: [PERFORM] Slow query when used in a view

Shaun Thomas writes: > A developer was complaining about a view he created to abstract an added > column in a left join. ... > Curious, I whipped up this test case: > CREATE VIEW v_slow_view AS > SELECT foo.*, tf.small_label IS NOT NULL AS has_small_label >FROM foo >LEFT JOIN tiny_foo tf

[PERFORM] Slow query when used in a view

Hey everyone! A developer was complaining about a view he created to abstract an added column in a left join. He was contemplating denormalizing the added value into the parent table and using a trigger to maintain it instead, and I obviously looked into the problem. I noticed the view was in

[PERFORM] The dreaded semwait on FreeBSD

I have a very heavy OLTP application in the field. We have two PostgreSQL databases (9.0.x)/FreeBSD 8.1/amd64 - one is a listener which just stores data digests, the other is the actual database. The digests from the listener are processed by multi-threaded daemons and inserted into the main data

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

Thanks again. The sorting does appear to be the issue. I will test out your cursor idea... On Mon, Mar 11, 2013 at 11:34 AM, Pavel Stehule wrote: > 2013/3/11 Jeff Adams - NOAA Affiliate : > > Pavel, > > > > Thanks for the response. I have not yet had the opportunity to use > cursors, > > but am n

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

2013/3/11 Jeff Adams - NOAA Affiliate : > Pavel, > > Thanks for the response. I have not yet had the opportunity to use cursors, > but am now curious. Could you perhaps provide a bit more detail as to what > the implementation of your suggested approach would look like? an example: $$ DECLARE r

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

Pavel, Thanks for the response. I have not yet had the opportunity to use cursors, but am now curious. Could you perhaps provide a bit more detail as to what the implementation of your suggested approach would look like? On Mon, Mar 11, 2013 at 11:03 AM, Pavel Stehule wrote: > Hello > > you can

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

Hello you can try procedural solution - use a cursor over ordered data in plpgsql and returns table Regards Pavel Stehule 2013/3/11 Jeff Adams - NOAA Affiliate : > Greetings, > > > > I have a large table (~90 million rows) containing vessel positions. In > addition to a column that contains the

Re: [PERFORM] sniff test on some PG 8.4 numbers

On Sun, Mar 10, 2013 at 11:28 PM, Greg Smith wrote: > On 3/10/13 9:18 PM, Jon Nelson wrote: > >> The following is with ext4, nobarrier, and noatime. As noted in the >> original post, I have done a fair bit of system tuning. I have the >> dirty_bytes and dirty_background_bytes set to 3GB and 2GB, >

[PERFORM] Large Table - Slow Window Functions (Better Approach?)

Greetings, I have a large table (~90 million rows) containing vessel positions. In addition to a column that contains the location information (the_geom), the table also contains two columns that are used to uniquely identify the vessel (mmsi and name) and a column containing the Unix time (epoc