From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghengan <pg(at)bowt(dot)ie>, "heikki(dot)linnakangas" <heikki(dot)linnakangas(at)iki(dot)fi> |
Subject: | Re: Proposal: Global Index |
Date: | 2019-10-30 16:23:23 |
Message-ID: | 28188.1572452603@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 30, 2019 at 10:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I believe that the current design of partitioning is explicitly intended
>> to avoid the need for such a construct. It'd be absolutely disastrous
>> to have such a thing from many standpoints, including the breadth of
>> locking needed to work with the global index, the difficulty of vacuuming,
>> and the impossibility of cheaply attaching or detaching partitions.
>> In other words, this is a "feature" we do not want.
> I don't think that's true. Certainly, a lot of EnterpriseDB customers
> want this feature - it comes up regularly in discussions here. But
> that is not to say that the technical challenges are not formidable,
> and I don't think this proposal really grapples with any of them.
> However, that doesn't mean that the feature isn't desirable.
Well, the *effects* of the feature seem desirable, but that doesn't
mean that we want an implementation that actually has a shared index.
As soon as you do that, you've thrown away most of the benefits of
having a partitioned data structure in the first place.
No, I don't have an idea how we might support, eg, uniqueness of
non-partition-key columns without that. But we need to spend our
effort on figuring that out, not on building a complicated mechanism
whose performance is never going to not suck.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2019-10-30 16:24:32 | Re: Parallel leader process info in EXPLAIN |
Previous Message | Robert Haas | 2019-10-30 16:16:03 | Re: tableam vs. TOAST |