On Mon, Sep 01, 2003 at 09:05:33AM -0400, Tom Lane wrote:
> Guy Thornley <[EMAIL PROTECTED]> writes:
> > Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> > boxen arnt killed for hours a day when VACUUM runs.
>
> Wasn't this idea tried and rejected already? You haven'
sad wrote:
> Good day
>
> is it possible to define user variables in session ?
> If not then is it planned to implement ?
> or it is principially impossible in PosqtgreSQL
psql has variables, but in general we don't support session varibles.
You could create a temp table and put a value in there
Tom Lane wrote:
> Guy Thornley <[EMAIL PROTECTED]> writes:
> > Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> > boxen arnt killed for hours a day when VACUUM runs.
>
> Wasn't this idea tried and rejected already? You haven't given us any
> information about actual
Good day
is it possible to define user variables in session ?
If not then is it planned to implement ?
or it is principially impossible in PosqtgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if yo
Guy Thornley <[EMAIL PROTECTED]> writes:
> Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> boxen arnt killed for hours a day when VACUUM runs.
Wasn't this idea tried and rejected already? You haven't given us any
information about actual performance.
> The usleep()
Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
boxen arnt killed for hours a day when VACUUM runs. Patch includes a
paragraph for the manual. The new setting is VACUUM_THROTTLE. It can be SET
from a client connection, too.
The usleep() could be replaced with a select(
Wayne Schroeder <[EMAIL PROTECTED]> writes:
> IMHO, it would be good for the last_value to come back null if is_called
> is false. Don't know if that's possible or even a good idea --
It's not really very practical; among other things you'd lose the
ability to specify a START value different from
IMHO, it would be good for the last_value to come back null if is_called
is false. Don't know if that's possible or even a good idea -- but
figured it was worth a note since the following psql log raised my eye
brow a bit.
Wayne
-
policy=> create sequence a s
