Re: [PATCHES] Updated Packed Varlena patch v20 (final?)
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?)
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
[PATCHES] Updated packed varlena patch
I added a little-endian special-case using the low order bits as described by Tom. Also, I noticed that int2vector and oidvector are already flagged in pg_type with attstorage == 'p'. Really any type with attstorage == 'p' should be exempted from packed varlena handling since it isn't expecting to be toasted. This lets me clean up heaptuple.c a bit so now it doesn't depend on pg_type.h and doesn't have any special case exemption for oidvector and int2vector. It also means any other type can opt out from packed varlena packing by setting attstorage. I've left inet and cidr with toast support and changed them to have attstorage 'm' instead. http://community.enterprisedb.com/varlena/patch-varvarlena-17.patch.gz -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
