Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
От | Robert Haas |
---|---|
Тема | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode |
Дата | |
Msg-id | CA+TgmoZOA7Co=6OrGrQ0Bu=xa4TtJ4SJb-vF3GQ32oAziCxTng@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Ответы |
RE: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
|
Список | 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
В списке pgsql-committers по дате отправления:
Следующее
От: Robert HaasДата:
Сообщение: Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode