Re: CUBE seems a bit confused about ORDER BY

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CUBE seems a bit confused about ORDER BY
Date: 2018-01-11 20:00:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> This was discussed upthread and the solution found was "objects need to
>> be rebuilt, indexes need to be reindexed". The point of Alexander's
>> query was to find affected objects that need such treatment. Teodor
>> explicitly disregarded any change in pg_upgrade because the database
>> you're upgrading *from* is supposed to have gotten indexes reindexed,
>> etc.
> I don't think that is really going to be acceptable. People do not like
> minor version updates that break their databases. If we start doing
> that we're going to find people refusing to apply minor updates, which
> is not a place we want to be.
That's true, but we have choice of bad solutions. Current index could
not support operator before patch. So we can:
1) Change operator to support existing index. That is what Alexander
did. And yes, it changes returning order for both sequential and
index scans, but makes them synced. Actually, user should not
reindex existing indexes but should be ready for order changing
2) Change index structure which isn't obvious how. At least, it's
possible to add new operator class (so, upgrade script is needed)
Mandatory reindex and order changes for index scans
3) Remove index support for this operator at all. And introduce new
operator in HEAD with index support. This will need an upgrade script
in minor versions

Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-01-11 20:06:31 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Esteban Zimanyi 2018-01-11 19:51:27 Parameters in user-defined aggregate final functions