[PATCHES] Packed varlena patch update
I implemented Tom's suggestion of packing the external toast pointers unaligned and copying them to a local struct to access the fields. This saves 3-6 bytes on every external toast pointer. Presumably this isn't interesting if you're accessing the toasted values since they would be quite large anyways, but it could be interesting if you're doing lots of queries that don't access the toasted values. It does uglify the code a bit but it's all contained in tuptoaster.c. http://community.enterprisedb.com/varlena/patch-varvarlena-19.patch.gz I think this is the last of the todo suggestions that were mentioned on the list previously, at least that I recall. Some implications: 1) There's no longer any macro to determine if an external attribute is compressed. I could provide a function to do it if we need it but in all the cases where I see it being used we already needed to extract the fields of the toast pointer anyways, so it wouldn't make sense. 2) We check if a toasted value is replaced with a new one by memcmp'ing the entire toast pointer. We used to just compare valueid and relid, so this means we're now comparing extsize and rawsize as well. I can't see how they could vary for the same valueid though so I don't think that's actually changing anything. Remaining things in the back of my mind though: . I'm not 100% confident of the GIST changes. I think I may have changed a few too many lines of code there. It does pass all the contrib regressions though. . I think there may be some opportunities for optimizing heaptuple.c. In particular the places where it uses VARSIZE_ANY where it knows some of the cases are impossible. It may not make a difference due to branch prediction though. . I've left the htonl/ntohl calls in place in the BIG_ENDIAN #if-branch. They're easy enough to remove and it leaves us the option of removing the #if entirely and just us use network-byte-order instead of the #ifdef. I'm a bit worried about modules building against postgres.h without including the config.h include file. Is that possible? Is it worth worrying about? I think I could make it fail to build rather than crash randomly. . One of the regression tests I wrote makes a datum of 1/2Meg. Can all the build-farm machines handle that? I don't really need anything so large for the regression but it was the most convenient way to make something which after compressing was large enough to toast externally. It might be better to find some less compressible data. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Packed varlena patch update
Gregory Stark wrote: I'm a bit worried about modules building against postgres.h without including the config.h include file. Is that possible? Is it worth worrying about? I think I could make it fail to build rather than crash randomly. postgres.h includes c.h which includes pg_config.h, so this is not a problem. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(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
