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
|
Список | 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 по дате отправления: