Thread: Why we have tuplestore and tuplesort?
Thinking about window function performance improvement as well as concerning about GROUPING SETS discussed a couple of days before, I wonder why we have both of tuplestore and tuplesort. They are very similar but have different functions such as multiple read pointer with tuplestore whereas perform_sort with tuplesort. If we integrate them, nodeWindowAgg, for instance, won't need Sort node before it and will be able to avoid redundant tuple copy from the tuplesort (on the Sort node) to the tuplestore. Looking for git/cvs log a bit, tuplesort was already there since 1999 while tuplestore was introduced around 2000 for materialized node. Why then was tuplestore invented as a new feature instead of extending tuplesort? Can't we unit them now? Regards, -- Hitoshi Harada
Hitoshi Harada <umi.tanuki@gmail.com> writes:
> Looking for git/cvs log a bit, tuplesort was already there since 1999
> while tuplestore was introduced around 2000 for materialized node. Why
> then was tuplestore invented as a new feature instead of extending
> tuplesort? Can't we unit them now?
I think they'd be unmaintainable if merged. Each one is complicated
enough as-is, and they have different concerns and different use-cases
to optimize for. Moreover it's not clear that merging them would buy us
much --- saving one copy step doesn't excite me, even if it actually
came out to be true which I'm unconvinced about.
regards, tom lane
2009/8/16 Tom Lane <tgl@sss.pgh.pa.us>: > Hitoshi Harada <umi.tanuki@gmail.com> writes: >> Looking for git/cvs log a bit, tuplesort was already there since 1999 >> while tuplestore was introduced around 2000 for materialized node. Why >> then was tuplestore invented as a new feature instead of extending >> tuplesort? Can't we unit them now? > > I think they'd be unmaintainable if merged. Each one is complicated > enough as-is, and they have different concerns and different use-cases > to optimize for. Moreover it's not clear that merging them would buy us > much --- saving one copy step doesn't excite me, even if it actually > came out to be true which I'm unconvinced about. > > regards, tom lane > I agree it would be unmaintainable. However it sounds like there's no crystal clear reason the two are separated. Before tuplestore got multiple read pointers it was quite similar to tuplestore except performing sort so I can imagine allowing tuplesort to have multiple read pointers. Regards, -- Hitoshi Harada
2009/8/16 Hitoshi Harada <umi.tanuki@gmail.com>: > 2009/8/16 Tom Lane <tgl@sss.pgh.pa.us>: >> Hitoshi Harada <umi.tanuki@gmail.com> writes: >>> Looking for git/cvs log a bit, tuplesort was already there since 1999 >>> while tuplestore was introduced around 2000 for materialized node. Why >>> then was tuplestore invented as a new feature instead of extending >>> tuplesort? Can't we unit them now? >> >> I think they'd be unmaintainable if merged. Each one is complicated >> enough as-is, and they have different concerns and different use-cases >> to optimize for. Moreover it's not clear that merging them would buy us >> much --- saving one copy step doesn't excite me, even if it actually >> came out to be true which I'm unconvinced about. >> >> regards, tom lane >> > > I agree it would be unmaintainable. However it sounds like there's no > crystal clear reason the two are separated. Before tuplestore got > multiple read pointers it was quite similar to tuplestore except oops, "similar to tuplesort" > performing sort so I can imagine allowing tuplesort to have multiple > read pointers. > > > Regards, > > -- > Hitoshi Harada > -- Hitoshi Harada