Thread: Patch for units in postgresql.conf

Patch for units in postgresql.conf

From
Peter Eisentraut
Date:
Here is a preliminary patch for units in postgresql.conf (and SET and so on,
of course).  It currently supports memory units only.  Time units would be
similar.  Let me know if you have comments.

(FWIW, work_mem is a good parameter to play with for trying this out.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Attachment

Re: Patch for units in postgresql.conf

From
Peter Eisentraut
Date:
Am Dienstag, 25. Juli 2006 15:12 schrieb Alvaro Herrera:
> Does this mean that one must match the "kB" exactly, with the specified
> upper and lower case?

I think it's better to require exact spelling of the units, or else it'll
quickly get inconsistent and error-prone.  (Say, if you want to allow "KB",
why not "mB"?  And "kb" is clearly a kilobit, so we don't want to allow that
in any case.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: Patch for units in postgresql.conf

From
Alvaro Herrera
Date:
Peter Eisentraut wrote:

> +    if ((flags & (GUC_UNIT_KB|GUC_UNIT_BLOCKS)) && endptr != value)
> +    {
> +        bool used = false;
> +
> +        while (*endptr == ' ')
> +            endptr++;
> +
> +        if (strcmp(endptr, "kB") == 0)
> +        {
> +            val *= KILOBYTE;
> +            used = true;
> +            endptr += 2;
> +        }

Does this mean that one must match the "kB" exactly, with the specified
upper and lower case?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Re: Patch for units in postgresql.conf

From
Zdenek Kotala
Date:
Peter Eisentraut wrote:
> Here is a preliminary patch for units in postgresql.conf (and SET and so on,
> of course).  It currently supports memory units only.  Time units would be
> similar.  Let me know if you have comments.

The concept is good. However, parse should generate overflow. You
multiply first time and convert value to bytes and after you divide it.
  By my opinion, better solution is compute number and
direction(multiply/divide) of shift bits and do it in one step.

There is small concept:

------------
    int shift_tab[][] = { { 0 , -10, -20, -30 },
             { 10,  0 , -10, -20 },
             { 20,  10,  0 , -10 },
             { 30,  20,  10,  0  },
             { shift for block   } };

if (strcmp(endptr, "kB") == 0)
        {
            shift = shift_tab[1][ flags & ..... ];
            used = true;
            endptr += 2;
        }

if( shift < 0 )
   val >> = shift;
else
{
   int mask = ~0;
   mask << = shift;
   if( val & mask == 0 )
     val << = shift;
   else
     ....!!! Overflow
}

--------------------


I am not sure but I expect that values are stored in native format
(native unit). I think, there is not reason to divide/multiply it?


> @@ -5082,8 +5124,34 @@
>                      val = (*conf->show_hook) ();
>                  else
>                  {
> -                    snprintf(buffer, sizeof(buffer), "%d",
> -                             *conf->variable);
> +                    char unit[3];
> +                    int result = *conf->variable;
> +
> +                    if (record->flags & (GUC_UNIT_KB|GUC_UNIT_BLOCKS))
> +                    {
> +                        if (record->flags & GUC_UNIT_BLOCKS)
> +                            result *= BLCKSZ/1024;
> +


        Zdenek