Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace - Mailing list pgsql-sql

From Adriaan Joubert
Subject Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Date
Msg-id 388D4D9D.C4569FBC@albourne.com
Whole thread Raw
In response to DISTINCT ON: speak now or forever hold your peace  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Chairudin Sentosa Harjo
Date:
Subject: Cannot flush block 9782
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace