Re: Parallel Seq Scan - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Parallel Seq Scan |
Date | |
Msg-id | CA+TgmoYg6oL5HWMEjWrhxamadd9-OgdH-SLu-SknTcAuootW=w@mail.gmail.com Whole thread Raw |
In response to | Re: Parallel Seq Scan (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Fri, Oct 23, 2015 at 12:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > BTW, my Salesforce colleagues have been bit^H^H^Hgriping for quite some > time about the performance costs associated with translating between > plpgsql's internal PLpgSQL_datum-array format and the ParamListInfo > representation. Maybe it's time to think about some wholesale redesign of > ParamListInfo? Because TBH this patch doesn't seem like much but a kluge. > It's mostly layering still-another bunch of ad-hoc restrictions on > copyParamList, without removing any one of the kluges we had already. I have no objection to some kind of a redesign there, but (1) I don't think we're going to be better off doing that before getting Partial Seq Scan committed and (2) I don't think I'm the best-qualified person to do the work. With respect to the first point, despite my best efforts, this feature is going to have bugs, and getting it committed in November without a ParamListInfo redesign is surely going to be better for the overall stability of PostgreSQL and the timeliness of our release schedule than getting it committed in February with such a redesign -- never mind that this is far from the only redesign into which I could get sucked. I want to put in place some narrow fix for this issue so that I can move forward. Three alternatives have been proposed so far: (1) this, (2) the fix I coded and posted previously, which made plpgsql_param_fetch's bms_is_member test unconditional, and (3) not allowing PL/pgsql to run parallel queries. (3) sounds worse to me than either (1) or (2); I defer to others on which of (1) and (2) is preferable, or perhaps you have another proposal. On the second point, I really don't know enough about the problems with ParamListInfo to know what would be better, so I can't really help there. If you do and want to redesign it, fine, but I really need whatever you replace it with have an easy way of serializing and restoring it - be it nodeToString() and stringToNode(), SerializeParamList and RestoreParamList, or whatever. Without that, parallel query is going to have to be disabled for any query involving parameters, and that would be, uh, extremely sad. Also, FWIW, in my opinion, it would be far more useful to PostgreSQL for you to finish the work on upper planner path-ification ... an awful lot of people are waiting for that to be completed to start their own work, or are doing work that may have to be completely redone when that lands. YMMV, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: