Re: [HACKERS] Re: attdisbursion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: attdisbursion
Date: 1999-09-17 14:58:49
Message-ID: 29306.937580329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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.

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...

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-09-17 15:43:17 Re: [HACKERS] Bug
Previous Message Tom Lane 1999-09-17 14:49:34 Re: [HACKERS] Join syntax