Re: [HACKERS] One-shot expanded output in psql using \gx

I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that

Re: [HACKERS] Press Release Draft - 2016-02-09 Cumulative Update

Am 08.02.2017 um 20:17 schrieb Alvaro Herrera : > Note that this is likely to fail if the original index name is close to > the 63 chars limit. Perhaps it's enough to add substring() when > computing index_name_tmp. (You could just not use :'index_name' there > and rely

Re: [HACKERS] Press Release Draft - 2016-02-09 Cumulative Update

Am 07.02.2017 um 18:44 schrieb Alvaro Herrera : > 80 CREATE INDEX CONCURRENTLY bad_index_name ON table_name (column_name); > /* replace names with your original index definition */ I was thinking if we could replace that "replace names with your original index

Re: [HACKERS] Draft release notes for next week's releases are up for review

er from commit log: s/Tobias Bussman/Tobias Bussmann/ thanks Tobias -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel execution and prepared statements

> I think if we don't see any impact then we should backpatch this > patch. However, if we decide to go some other way, then I can provide > a separate patch for back branches. BTW, what is your opinion? I could not find anything on backporting guidelines in the wiki but my opinion would be to

Re: [HACKERS] Parallel execution and prepared statements

> On Thu, Dec 1, 2016 at 9:40 PM, Robert Haas wrote: >> >> OK, then my vote is to do it that way for now. Thanks for your opinion. That's fine with me. > Am 02.12.2016 um 07:22 schrieb Amit Kapila : > Done that way in attached patch. Did a

Re: [HACKERS] Fix typo in ecpg.sgml

> Right, and the "SQL" was missing, too. Thanks for spotting, fixed in > HEAD. oops. Thanks for taking care. Tobias -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Fix typo in ecpg.sgml

Hi, there is a missing "EXEC" in ecpg.sgml in the list of transaction management commands. Attached a trivial patch to fix this. Best regards Tobias ecpg-doc-typo.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Parallel execution and prepared statements

Am 18.11.2016 um 14:21 schrieb Albe Laurenz : > But then the change to use CURSOR_OPT_PARALLEL_OK in tcop/postgres.c should > be reverted as well, because it breaks things just as bad: > > /* creates a parallel-enabled plan */ > PQprepare(conn, "pstmt", "SELECT id

Re: [HACKERS] Parallel execution and prepared statements

> True, but we also try to avoid it whenever possible, because it's > likely to lead to poor performance. This non-readonly case should be way less often hit compared to other uses of prepared statements. But sure, it depends on the individual use case and a likely performance regession in

Re: [HACKERS] Parallel execution and prepared statements

have any parameters. Additionally, influencing the decision and generating a non-parallel plan would shift the avg cost calculation used to choose custom or generic plans. Maybe someone can come up with a better idea for a solution. These three approaches are all I see so far. Best regard

Re: [HACKERS] Parallel execution and prepared statements

> Can you once test by just passing CURSOR_OPT_PARALLEL_OK in > PrepareQuery() and run the tests by having forc_parallel_mode=regress? > It seems to me that the code in the planner is changed for setting a > parallelModeNeeded flag, so it might work as it is. Do you mean running a "make

Re: [HACKERS] Parallel execution and prepared statements

As the patch in [1] targeting the execution of the plan in ExecutePlan depending on the destination was declined, I hacked around a bit to find another way to use parallel mode with SQL prepared statements while disabling the parallel execution in case of an non read-only execution. For this I

Re: [HACKERS] Parallel execution and prepared statements

J7jZBvqxfQ%40mail.gmail.com [2] https://www.postgresql.org/docs/current/static/when-can-parallel-query-be-used.html > Am 15.11.2016 um 16:41 schrieb Albe Laurenz <laurenz.a...@wien.gv.at>: > > Tobias Bussmann has discovered an oddity with prepared statements. > > Parallel scan i

Re: [HACKERS] extract text from XML

> I have found a basic use case which is supported by the xml2 module, > but is unsupported by the new XML API. > It is not possible to correctly extract text Indeed. I came accross this shortcomming some months ago myself but still manage an item on my ToDo list to report it here as the