On Fri, Jan 8, 2021 at 11:26:48AM +0800, 曾文旌 wrote:
> > On Thu, Jan 7, 2021 at 05:44:01PM +0800, 曾文旌 wrote:
> >> I've been following this topic for a long time. It's been a year since the last response.
> >> It was clear that our customers wanted this feature as well, and a large number of them mentioned it.
> >>
> >> So, I wish the whole feature to mature as soon as possible.
> >> I summarized the scheme mentioned in the email and completed the POC patch(base on PG_13).
> >
> > I think you need to address the items mentioned in this blog, and the
> > email link it mentions:
> >
> > https://momjian.us/main/blogs/pgblog/2020.html#July_1_2020
>
> Thank you for your reply.
> I read your blog and it helped me a lot.
>
> The blog mentions a specific problem: "A large global index might also reintroduce problems that prompted the
creationof partitioning in the first place. "
> I don't quite understand, could you give some specific information?
Well, if you created partitions, you probably did so because:
1. heap files are smaller, allowing for more targeted sequential scans
2. smaller indexes
3. the ability to easily drop tables/indexes that are too old
If you have global indexes, #1 is the same, but #2 is not longer true,
and for #3, you can drop the heap but the index entries still exist in
the global index and must be removed.
So, if you created partitions for one of the three reasons, once you
have global indexes, some of those advantage of partitioning are no
longer true. I am sure there are some workloads where the advantages of
partitioning, minus the advantages lost when using global indexes, are
useful, but are there enough of them to make the feature useful? I
don't know.
> In addition you mentioned: "It is still unclear if these use-cases justify the architectural changes needed to enable
globalindexes."
> Please also describe the problems you see, I will confirm each specific issue one by one.
Well, the email thread I linked to has a lot of them, but the
fundamental issue is that you have to break the logic that a single
index serves a single heap file. Considering what I said above, is
there enough usefulness to warrant such an architectural change?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
