Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2008-03-24 Thread Bruce Momjian
Added to TODO: * Research reducing deTOASTing in more places http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php --- Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-11-03 Thread Bruce Momjian
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Ok, this

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-10-11 Thread Gregory Stark
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: (It might be interesting to make textin produce a packed result when possible, just to see what breaks; but I would be afraid to try to do that for production...) Reassuringly all checks pass with a hack like that

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-10-11 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: For the record I've been doing some more testing and found one place that could be a problem down the road. I'm not sure why it didn't show up previously. In selfuncs.c we use VARDATA/VARSIZE on data that is taken from parser Const nodes and from the

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-10-11 Thread Tom Lane
I wrote: In fact, it seems there's a different risk here: if such a datum were toasted out-of-line, the reference in a cached plan might live longer than the underlying toast-table data. Maybe we need a forcible detoast in evaluate_function(). Sure enough, it seems we do. The attached

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-24 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: (It might be interesting to make textin produce a packed result when possible, just to see what breaks; but I would be afraid to try to do that for production...) Reassuringly all checks pass with a hack like that in place. (attached) I think the right

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-23 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Ok, this removes what should be most if not all of the call sites where we're detoasting text or byteas. In particular it gets all the regexp/like functions and all the trim/pad functions. It also gets hashtext and

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-23 Thread Andrew Dunstan
Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Ok, this removes what should be most if not all of the call sites where we're detoasting text or byteas. In particular it gets all the regexp/like functions and all the trim/pad

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-23 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: This may have been a misdiagnosis of the buildfarm failures but it looks like a correct bug fix to me. That is, it looks like regexp_split_to_array() was capable of passing a packed varlena to setup_regexp_matches which wasn't expecting it. But this I

Re: [HACKERS] [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-23 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: (It might be interesting to make textin produce a packed result when possible, just to see what breaks; but I would be afraid to try to do that for production...) This all brings up the question of what other files