Re: MULTISET and additional functions for ARRAY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MULTISET and additional functions for ARRAY
Date: 2010-11-15 19:38:36
Message-ID: 5094.1289849916@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> On Mon, Nov 15, 2010 at 10:13:40AM -0500, Tom Lane wrote:
>> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
>>> Another issue for sorting is that we have 4 kinds of sorting: ASC/DESC
>>> and NULLS FIRST/LAST.

>> We have a lot more kinds than that. See USING.

> USING pretty much gives us no chance of optimizing at all. Could we
> maybe see about optimizing the 99% case, which those two bits cover?

The question is why support more than *one* kind, if you're only
supporting a subset. I don't see the value of messing with stuff like
NULLS FIRST if you're not going to go all the way. What's more, the
alleged use for this is strictly as an internal optimization in multiset
representation, so there's no reason to support more than one sort
order.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-15 19:41:51 Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal
Previous Message Robert Haas 2010-11-15 19:30:53 Re: Instrument checkpoint sync calls