On Tue, Mar 23, 2021 at 11:13 PM [email protected] <[email protected]> wrote: > One problem with caching the result is that the first access in each session > has to experience the slow processing. Some severe customers of our > proprietary database, which is not based on Postgres, have requested to > eliminate even the overhead associated 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 committer in PG 14, can be used to allow users to > execute possible queries at session start (or establishing a connection > pool), 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's only 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 that the 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 discussion of the software and this > community, their current state, and possible directions for development. The > focus of our 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 explanation in 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
