Re: [HACKERS] Re: attdisbursiont
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: attdisbursiont |
Дата | |
Msg-id | 199909171547.LAA19253@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: attdisbursion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: attdisbursiont
|
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Added to TODO. This will improve VACUUM ANALYZE performance, thought I > > don't think we have btree comparison functions for all data types, > > though we should: > > > * change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls > > There are several places that know more than they should about the > meaning of "<" etc operators. For example, the parser assumes it > should use "<" and ">" to implement ORDER BY [DESC]. Making VACUUM > not depend on specific names for the ordering operators will not > improve life unless we fix *all* of these places. Actually, I thought it would be good for performance reasons, not for portability. We would call one function per attribute instead of three. > > Rather than depending on btree to tell us which way is up, maybe the > pg_type row for a type ought to specify the standard ordering operators > for the type directly. > > While we are at it we could think about saying that there is just one > "standard ordering operator" for a type and it yields a strcmp-like > result (minus, zero, plus) rather than several ops yielding booleans. > But that'd take a lot of changes in btree and everywhere else... > The btree comparison functions do just that, returning -1,0,1 like strcmp, for each type btree supports. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: