Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode - Mailing list pgsql-committers

On Tue, Mar 23, 2021 at 11:13 PM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
> One problem with caching the result is that the first access in each session has to experience the slow processing.
Somesevere customers of our proprietary database, which is not based on Postgres, have requested to eliminate even the
overheadassociated with the first access, and we have provided features for them.  As for the data file, users can use
pg_prewam. But what can we recommend users to do in this case?  Maybe the logon trigger feature, which is ready for
committerin PG 14, can be used to allow users to execute possible queries at session start (or establishing a
connectionpool), but I feel it's inconvenient. 

Well, I don't mind if somebody thinks up an even better solution.

> Regarding the picked xid assignment, I didn't think it's so grotty.  Yes, in fact, I felt it's a bit unclean.  But
it'sonly a single line of code.  With a single line of code, we can provide great value to users.  Why don't we go for
it? As discussed in the thread, the xid is wasted only when the source data is empty, which is impractical provided
thatthe user wants to load much data probably for ETL. 

The amount of code isn't the issue. I'd rather expend a little more
code and solve the problem in a better way.

> (I'm afraid "grotty" may be too strong a word considering the CoC statement "We encourage thoughtful, constructive
discussionof the software and this community, their current state, and possible directions for development. The focus
ofour discussions should be the code and related technology, community projects, and infrastructure.") 

I did not mean to give offense, but I also don't think grotty is a
strong word. I consider it a pretty mild word.

> > Likewise, the XXX comment you added to max_parallel_hazard_walker
> > claims that some of the code introduced there is to compensate for an
> > unspecified bug in the rewriter. I'm a bit skeptical that the comment
> > is correct, and there's no way to find out because the comment doesn't
> > say what the bug supposedly is, but let's just say for the sake of
> > argument that it's true. Well, you *could* have fixed the bug, but
> > instead you hacked around it, and in a relatively expensive way that
> > affects every query with a CTE in it whether it can benefit from this
> > patch or not. That's not a responsible way of maintaining the core
> > PostgreSQL code.
>
> It'd be too sad if we have to be bothered by an existing bug and give up an attractive feature.  Adding more
explanationin the comment is OK?  Anyway, I think we can separate this issue. 

I don't think I agree. These checks are adding a significant amount of
overhead, and one of the problems with this whole thing is that it
adds a lot of overhead.

--
Robert Haas
EDB: http://www.enterprisedb.com