Thread: Re: [PATCHES] Last infomask bit

Re: [PATCHES] Last infomask bit

From

Tom Lane

Date:

09 January 2007, 21:29:38

Bruce Momjian <bruce@momjian.us> writes:
> Patch applied.  Thanks.
> I added a comment about the unused bits in the header file.

Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value?  This is not a zero-cost improvement.

            regards, tom lane

Re: [PATCHES] Last infomask bit

From

Bruce Momjian

Date:

09 January 2007, 21:35:30

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Patch applied.  Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value?  This is not a zero-cost improvement.

I assumed Heikki had tested it, but now see no mention of a test in the
posting:

    http://archives.postgresql.org/pgsql-patches/2007-01/msg00052.php

Tom, how should this be tested?  I assume some loop of the same query
over and over again.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: [PATCHES] Last infomask bit

From

Bruce Momjian

Date:

09 January 2007, 21:40:22

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Patch applied.  Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value?  This is not a zero-cost improvement.

SHOW ALL has:

   log_temp_files                  | -1                             | Log the use of temporary files larger than th

and pg_settings has:

   log_temp_files    | -1      | kB  | Reporting and Logging / What to Log

Looks OK to me.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: [PATCHES] Last infomask bit

From

Tom Lane

Date:

09 January 2007, 21:43:14

Bruce Momjian <bruce@momjian.us> writes:

> SHOW ALL has:

>    log_temp_files                  | -1                             | Log the use of temporary files larger than th

Yeah, but if you do "SET log_temp_files = -1", does it still say that?
I'm worried that will change it to -1024.

            regards, tom lane

Re: [PATCHES] Last infomask bit

From

Tom Lane

Date:

09 January 2007, 21:44:15

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Has anyone bothered to measure the overhead added by having to mask to
>> fetch or store the natts value?  This is not a zero-cost improvement.

> Tom, how should this be tested?  I assume some loop of the same query
> over and over again.

I'd be satisfied by a demonstration of no meaningful difference in
pgbench numbers.

It's *probably* not a problem, but you never know if you don't check...

            regards, tom lane

Re: [PATCHES] Last infomask bit

From

Bruce Momjian

Date:

09 January 2007, 21:44:49

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>
> > SHOW ALL has:
>
> >    log_temp_files                  | -1                             | Log the use of temporary files larger than th
>
> Yeah, but if you do "SET log_temp_files = -1", does it still say that?
> I'm worried that will change it to -1024.

You can rest easy tonight.  :-)

    test=> SET log_temp_files = -1;
    SET
    test=> SHOW log_temp_files;
     log_temp_files
    ----------------
     -1
    (1 row)

    test=> SET log_temp_files = 1;
    SET
    test=> SHOW log_temp_files;
     log_temp_files
    ----------------
     1kB
    (1 row)

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: [PATCHES] Last infomask bit

From

Heikki Linnakangas

Date:

10 January 2007, 08:49:31

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Patch applied.  Thanks.
>>> I added a comment about the unused bits in the header file.
>> Has anyone bothered to measure the overhead added by having to mask to
>> fetch or store the natts value?  This is not a zero-cost improvement.
>
> SHOW ALL has:
>
>    log_temp_files                  | -1                             | Log the use of temporary files larger than th
>
> and pg_settings has:
>
>    log_temp_files    | -1      | kB  | Reporting and Logging / What to Log
>
> Looks OK to me.

What? I'm completely lost here. What does log_temp_files have to do with
the bits on the tuple header?

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Re: [PATCHES] Last infomask bit

From

Heikki Linnakangas

Date:

10 January 2007, 09:06:40

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Tom Lane wrote:
>>> Has anyone bothered to measure the overhead added by having to mask to
>>> fetch or store the natts value?  This is not a zero-cost improvement.

I haven't tested it. Agreed, it does add an AND operation to places
where t_natts is accessed.

>> Tom, how should this be tested?  I assume some loop of the same query
>> over and over again.
>
> I'd be satisfied by a demonstration of no meaningful difference in
> pgbench numbers.
>
> It's *probably* not a problem, but you never know if you don't check...

I doubt there's any measurable difference, but I can do a pgbench run to
make sure.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Re: [pgsql-patches] [PATCHES] Last infomask bit

From

Tom Lane

Date:

10 January 2007, 13:30:34

Heikki Linnakangas <heikki@enterprisedb.com> writes:
> What? I'm completely lost here. What does log_temp_files have to do with
> the bits on the tuple header?

Nothing, it looks like Bruce replied to the wrong message at one point
while these two threads were active ...

            regards, tom lane

Re: [PATCHES] Last infomask bit

From

Bruce Momjian

Date:

10 January 2007, 15:22:25

Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>> Patch applied.  Thanks.
> >>> I added a comment about the unused bits in the header file.
> >> Has anyone bothered to measure the overhead added by having to mask to
> >> fetch or store the natts value?  This is not a zero-cost improvement.
> >
> > SHOW ALL has:
> >
> >    log_temp_files                  | -1                             | Log the use of temporary files larger than th
> >
> > and pg_settings has:
> >
> >    log_temp_files    | -1      | kB  | Reporting and Logging / What to Log
> >
> > Looks OK to me.
>
> What? I'm completely lost here. What does log_temp_files have to do with
> the bits on the tuple header?

Sorry, Tom wanted two things tested and I replied to the wrong email.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: [PATCHES] Last infomask bit

From

Heikki Linnakangas

Date:

11 January 2007, 09:57:11

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Tom Lane wrote:
>>> Has anyone bothered to measure the overhead added by having to mask to
>>> fetch or store the natts value?  This is not a zero-cost improvement.
>
>> Tom, how should this be tested?  I assume some loop of the same query
>> over and over again.
>
> I'd be satisfied by a demonstration of no meaningful difference in
> pgbench numbers.

I ran pgbench on CVS checkout taken before the patch was applied, and I
couldn't measure a difference.

I got 1329-1340 TPM from three runs both with and without the patch. The
tests were run on my laptop, with scaling factor 10, using "pgbench
postgres -t 100000 -v", with fsync and full_page_writes disabled to make
it CPU bound, while observing top to confirm that CPU usage was 100%
during the test.

I think that's enough performance testing for this patch.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com