Re: asynchronous and vectorized execution
От | Robert Haas |
---|---|
Тема | Re: asynchronous and vectorized execution |
Дата | |
Msg-id | CA+TgmoY+SUiW5hP6MM-tGcVXsGYPF3urGoAAz0s57P3dickc+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: asynchronous and vectorized execution (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: asynchronous and vectorized execution
(Andres Freund <andres@anarazel.de>)
|
Список | pgsql-hackers |
On Wed, May 11, 2016 at 11:49 AM, Andres Freund <andres@anarazel.de> wrote: > On 2016-05-11 10:12:26 -0400, Robert Haas wrote: >> > I've to admit I'm not that convinced about the speedups in the !fdw >> > case. There seems to be a lot easier avenues for performance >> > improvements. >> >> What I'm talking about is a query like this: >> >> SELECT * FROM inheritance_tree_of_foreign_tables WHERE very_rarely_true; > > Note that I said "!fdw case". Oh, wow, I totally missed that exclamation point. >> > FWIW, I've even hacked something up for a bunch of simple queries, and >> > the performance improvements were significant. Besides it only being a >> > weekend hack project, the big thing I got stuck on was considering how >> > to exactly determine when to batch and not to batch. >> >> Yeah. I think we need a system for signalling nodes as to when they >> will be run to completion. But a Boolean is somehow unsatisfying; >> LIMIT 1000000 is more like no LIMIT than it it is like LIMIT 1. I'm >> tempted to add a numTuples field to every ExecutorState and give upper >> nodes some way to set it, as a hint. > > I was wondering whether we should hand down TupleVectorStates to lower > nodes, and their size determines the max batch size... There's some appeal to that, but it seems complicated to make work. >> >> Some care is required here because any >> >> functions we execute as scan keys are run with the buffer locked, so >> >> we had better not run anything very complicated. But doing this for >> >> simple things like integer equality operators seems like it could save >> >> quite a few buffer lock/unlock cycles and some other executor overhead >> >> as well. >> > >> > Hm. Do we really have to keep the page locked in the page-at-a-time >> > mode? Shouldn't the pin suffice? >> >> I think we need a lock to examine MVCC visibility information. A pin >> is enough to prevent a tuple from being removed, but not from having >> its xmax and cmax overwritten at almost but not quite exactly the same >> time. > > We already batch visibility lookups in page-at-a-time > mode. Cf. heapgetpage() / scan->rs_vistuples. So we can evaluate quals > after releasing the lock, but before the pin is released, without that > much effort. IIRC that isn't used for index lookups, but that's > probably a good idea. The trouble with that is that if you fail the qual, you have to relock the page. Which kinda sucks, if the qual is really simple. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: