| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Thomas Kellerer <shammat(at)gmx(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
| Subject: | Re: Patch: Global Unique Index |
| Date: | 2022-11-25 03:21:55 |
| Message-ID: | CAFiTN-vgrzcNhsc98iAF_-dzXwfQLKGo6YzF9ydAkUkvR39H4Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 25, 2022 at 8:49 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Thu, Nov 24, 2022 at 9:39 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > On Thu, Nov 24, 2022 at 08:52:16PM +0530, Dilip Kumar wrote:
> > > but now you will have one gigantic index and which will be vacuumed
> > > every time we vacuum any of the partitions.
> >
> > This patch isn't implemented as "one gigantic index", though.
>
> If this patch is for supporting a global index then I expect that the
> global index across all the partitions is going to be big. Anyway, my
> point was about vacuuming the common index every time you vacuum any
> of the partitions of the table is not the right way and that will make
> global indexes less usable.
Okay, I got your point. After seeing the details it seems instead of
supporting one common index it is just allowing uniqueness checks
across multiple index partitions. Sorry for the noise.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-11-25 03:26:00 | Re: Bug in row_number() optimization |
| Previous Message | Dilip Kumar | 2022-11-25 03:19:19 | Re: Patch: Global Unique Index |