From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
Subject: | Re: IN, BETWEEN, spec compliance, and odd operator names |
Date: | 2008-08-25 19:19:55 |
Message-ID: | 933F1E03-686E-41C1-BD91-0EA9302934ED@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Le 25 août 08 à 16:48, Tom Lane a écrit :
>> But, IIRC, only in the context of index searches, not at the
>> planner level.
>
> No, that's not true at all. There are lots and lots of places now
> where
> we use btree and/or hash operator classes to reason about the
> properties
> of operators.
Yes, but always in relation to operator classes, so from BTrees
opclass or such, which I refered to as "the context of index
searches", as I don't really see any theorical need for opclass if
it's not for indexing.
My formulation was "outright wrong", as you would say, but I hope to
have explained a little better what I'm on: there's not enough direct
semantic information concerning operators for the planner to take full
profit out if it. It this assertion more true?
Regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkizBdsACgkQlBXRlnbh1blP5wCgh5h3vAn8EUonABN0ZYV58JQe
xjMAoMpBNMiBLat1lfwGEz0w6rQip8LP
=Lgxd
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-25 19:43:08 | Re: IN, BETWEEN, spec compliance, and odd operator names |
Previous Message | Steve Atkins | 2008-08-25 18:43:48 | Re: Proposal: new border setting in psql |