Re: [PERFORM] batch update query performance

2014-04-13 Thread Jeff Janes
On Tue, Apr 8, 2014 at 6:21 AM, Hans Drexler < hans.drex...@humaninference.com> wrote: > Dear Jeff, Albe and Heikki, > > Let me start by thanking you for your time. It is really nice to have a > real supportive community. Thank you. > > After reading the answers, we decided to do an experiment wit

Re: [PERFORM] batch update query performance

2014-04-12 Thread Hans Drexler
Dear Jeff, Albe and Heikki, Let me start by thanking you for your time. It is really nice to have a real supportive community. Thank you. After reading the answers, we decided to do an experiment with a fillfactor of 40% and dropping the index on the is_grc_002 field (but retaining the other inde

Re: [PERFORM] Batch update query performance

2014-04-07 Thread Jeff Janes
On Fri, Apr 4, 2014 at 5:00 AM, Hans Drexler < hans.drex...@humaninference.com> wrote: > > update t67cdi_nl_cmp_descr set is_grc_002='Y' > > This post contains the data of two runs of the query. the first with > explain analyze. The second run is with explain buffers. Between the > runs, an explic

Re: [PERFORM] Batch update query performance

2014-04-07 Thread Heikki Linnakangas
On 04/07/2014 03:06 PM, Albe Laurenz wrote: Hans Drexler wrote: Postgres needs close to 50 minutes to process the same query on the same data. Sometimes, Postgres needs more than 2 hours. The application performs an update query on every row of the table. The exact SQL of this query is: update

Re: [PERFORM] Batch update query performance

2014-04-07 Thread Albe Laurenz
Hans Drexler wrote: > We are porting an application to PostgreSQL. The appplication already > runs with DB2 (LUW version) and Oracle. One query in particular executes > slower on Postgres than it does on other Database platforms, notably DB2 > LUW and Oracle. (Please understand, we are not comparin