Re: gsoc, oprrest function for text search take 2
От | ju219721@students.mimuw.edu.pl |
---|---|
Тема | Re: gsoc, oprrest function for text search take 2 |
Дата | |
Msg-id | 20080919102940.57oc3es3wogocg8o@students.mimuw.edu.pl обсуждение исходный текст |
Ответ на | Re: gsoc, oprrest function for text search take 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: gsoc, oprrest function for text search take 2
|
Список | pgsql-hackers |
Quoting Tom Lane <tgl@sss.pgh.pa.us>: > I wrote: >> ... One possibly >> performance-relevant point is to use DatumGetTextPP for detoasting; >> you've already paid the costs by using VARDATA_ANY etc, so you might >> as well get the benefit. > > Actually, wait a second. That code doesn't work at all on toasted data, > because it's trying to use VARSIZE_ANY_EXHDR() before detoasting. > That would give you the physical datum size (eg the size of the toast > pointer), not the number you need. > > However, this is actually not a problem because we know that the data > came from an array in pg_statistic, which means the individual members > *can't be toasted*. At least they can't be compressed or out-of-line. > We'd do that at the array level, it's not sensible to do it on an > individual array member. > > I think that right at the moment the array stuff doesn't permit short > headers either, but it would make sense to relax that someday. So I'd > recommend that your code allow either regular or short headers, but not > worry about compression or out-of-line storage. > > Which boils down to: keep using VARSIZE_ANY_EXHDR/VARDATA_ANY, but > forget the "detoasting" step. Maybe put in > Assert(!VARATT_IS_COMPRESSED(datum) && !VARATT_IS_EXTERNAL(datum)) > instead. Tom, Heikki, everyone, just to let you know - I haven't forgot about this, but right now I'm porting myself to another country, so things are quite hectic ;) I'll pick up the patch in a couple of weeks, so I'm sure it will be ready for the November CF. Thanks, Jan
В списке pgsql-hackers по дате отправления: