Re: [PATCHES] Updated Packed Varlena patch v20 (final?)

2007-03-22 Thread Bruce Momjian

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---


Gregory Stark wrote:
 
 Updated patch:
 
 I went through the high traffic areas and levelled them up to using the new
 macros to avoid detoasting smaller arguments. They key areas are really
 btree operators since they have a noticeable effect on sorts, especially index
 builds, when the data being sorted fits in memory.
 
 There is a bit of a name-game here. The macros I made are called
 VARDATA_ANY(datum) VARSIZE_ANY(datum) AND VARSIZE_ANY_EXHDR(datum). 
 And the datatype macros are, for example,  PG_GETARG_TEXT_PP() and
 DatumGetTextPP()  -- short for packed pointer.
 
 Maybe not the prettiest names in the world but clear and I've found them
 pretty easy to spot when I'm looking for inconsistent use of
 VARSIZE_ANY-VARDATA for example. I thought of PVARSIZE/PVARDATA (for
 packed) but I'm afraid it would camouflage such cases.
 
 Anyone have any better ideas? If not I'm satisfied with them... 
 Except maybe VARSIZE_ANY_EXHDR() which seems too long.
 
 I got to almost everything in varlena.c and varchar.c so that includes text,
 bpchar, and bytea as well as varchar's few procedures. That includes probably
 more than I really needed to, but as long as the datatypes are working with
 bytes it's convenient enough.
 
 Also, I replaced my tweaks to hstore and pg_trgm with Teodore's.
 
 And of course updated CVS.
 
  http://community.enterprisedb.com/varlena/varvarlena-20.patch.gz
 
 I'm going to be putting this aside for a little while. I think it's really
 done. There's more that can be done of course, hit inet and numeric with the
 new macros, for instance. But I want to see what happens when it gets reviewed
 before I do that kind of bookkeeping.
 
 One thing that I've left in there again is the htonl/ntohl macros in the
 big-endian case. It really makes sense to either remove them or remove the
 #ifdef.
 
 -- 
   Gregory Stark
   EnterpriseDB  http://www.enterprisedb.com
 
 ---(end of broadcast)---
 TIP 5: don't forget to increase your free space map settings

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


[PATCHES] Updated Packed Varlena patch v20 (final?)

2007-03-13 Thread Gregory Stark

Updated patch:

I went through the high traffic areas and levelled them up to using the new
macros to avoid detoasting smaller arguments. They key areas are really
btree operators since they have a noticeable effect on sorts, especially index
builds, when the data being sorted fits in memory.

There is a bit of a name-game here. The macros I made are called
VARDATA_ANY(datum) VARSIZE_ANY(datum) AND VARSIZE_ANY_EXHDR(datum). 
And the datatype macros are, for example,  PG_GETARG_TEXT_PP() and
DatumGetTextPP()  -- short for packed pointer.

Maybe not the prettiest names in the world but clear and I've found them
pretty easy to spot when I'm looking for inconsistent use of
VARSIZE_ANY-VARDATA for example. I thought of PVARSIZE/PVARDATA (for
packed) but I'm afraid it would camouflage such cases.

Anyone have any better ideas? If not I'm satisfied with them... 
Except maybe VARSIZE_ANY_EXHDR() which seems too long.

I got to almost everything in varlena.c and varchar.c so that includes text,
bpchar, and bytea as well as varchar's few procedures. That includes probably
more than I really needed to, but as long as the datatypes are working with
bytes it's convenient enough.

Also, I replaced my tweaks to hstore and pg_trgm with Teodore's.

And of course updated CVS.

 http://community.enterprisedb.com/varlena/varvarlena-20.patch.gz

I'm going to be putting this aside for a little while. I think it's really
done. There's more that can be done of course, hit inet and numeric with the
new macros, for instance. But I want to see what happens when it gets reviewed
before I do that kind of bookkeeping.

One thing that I've left in there again is the htonl/ntohl macros in the
big-endian case. It really makes sense to either remove them or remove the
#ifdef.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings