Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace

Поиск
Список
Период
Сортировка
От Adriaan Joubert
Тема Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Дата
Msg-id 388D4D9D.C4569FBC@albourne.com
обсуждение исходный текст
Ответ на DISTINCT ON: speak now or forever hold your peace  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-sql
Tom Lane wrote:

> Chris Bitmead <chris@bitmead.com> writes:
> > Tom Lane wrote:
> >> If I don't hear loud hollers very soon, I'm going to eliminate the
> >> DISTINCT ON "feature" for 7.0.  As previously discussed, this feature
> >> is not standard SQL and has no clear semantic interpretation.
>
> > I don't feel overly strongly about this, but if I remember right you can
> > do some pretty cool things with this feature, provided you do define
> > some semantics clearly.
>
> We did talk about that, but I didn't hear any strong support for doing
> it, as opposed to pulling the feature completely... in particular,
> I didn't hear anyone volunteering to do the work...

I've been using DISTINCT to fix things when vacuum gets into a mess (yes, it
happened again last night,
FATAL 1:  VACUUM (vc_rpfheap): BlowawayRelationBuffers returned -2
). I then have loads of duplicates in a table and by doing a SELECT DISTINCT
... INTO ... I can get rid of them. A few table renames later I'm back in
business. So how do I do this without DISTINCT?

Better would be of course to get rid of the BlowawayRelationBuffers problem.
I cannot reproduce it yet, but I think I can make it happen by running vacuum
and updating tables that are linked by triggers. Does this sound plausible?
And yes, I'm running on Alpha, i.e. 64 bits.

Adriaan



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

Предыдущее
От: Chairudin Sentosa Harjo
Дата:
Сообщение: Cannot flush block 9782
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace