Skip site navigation (1) Skip section navigation (2)

Re: Implementing cost limit/delays forinsert/delete/update/select

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implementing cost limit/delays forinsert/delete/update/select
Date: 2008-08-26 11:03:37
Message-ID: 1219748617.5343.1310.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2008-08-25 at 22:39 +0200, Peter Schuller wrote:

> Does this sound vaguely sensible? Is there an obvious show-stopper I
> am missing?

This was a well structured proposal.

The main problem is where you put the delay_point() calls. If you put
them at the top of the executor then you will get a delay proportional
to the number of rows retrieved. For many queries, such as count(*) this
might be just one row, yet have run for hours. There's no point having a
priority scheme if it doesn't apply to all queries equally.

If you put them at each call of each node then you will get an
unacceptable overhead as Tom suggests.

Not sure what to suggest, if anything, apart from just writing your own
delay() function and using it in your query.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-08-26 12:03:47
Subject: Re: gsoc, oprrest function for text search take 2
Previous:From: Dave CramerDate: 2008-08-26 10:59:38
Subject: Re: can't stop autovacuum by HUP'ing the server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group