Re: Rethinking representation of sort/hash semantics in queries and plans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rethinking representation of sort/hash semantics in queries and plans
Дата
Msg-id 21713.1290979219@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rethinking representation of sort/hash semantics in queries and plans  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> So to fix these problems we'd need to replace sort operator OIDs in
>> SortGroupClause and plan nodes with those three items.  Obviously, this
>> would be slightly bulkier, but the extra cost added to copying parse and
>> plan trees should be tiny compared to the avoided syscache lookups.

> My understanding is that opfamily+datatype gives an opclass. What about
> storing the opclass OID there?

Then you'd just need to look up the opfamily again.  Opclasses are too
small a division to be useful.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: profiling connection overhead
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [GENERAL] column-level update privs + lock table