Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Oct 6, 2017 at 12:29 AM, Robert Haas wrote: > On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi > wrote: > > There are some differences in handling database objects > > between pg_dump and pg_dumpall, To retain both pg_dump > > and

Re: [HACKERS] A design for amcheck heapam verification

On Thu, Oct 5, 2017 at 7:00 PM, Peter Geoghegan wrote: > v3 of the patch series, attached, does it that way -- it adds a > bloom_create(). The new bloom_create() function still allocates its > own memory, but does so while using a FLEXIBLE_ARRAY_MEMBER. A > separate bloom_init()

Re: [HACKERS] A GUC to prevent leader processes from running subplans?

On Tue, Oct 17, 2017 at 7:27 AM, Thomas Munro wrote: > While testing parallelism work I've wanted to be able to prevent > gather nodes from running the plan in the leader process, and I've > heard others say the same. One way would be to add a GUC >

[HACKERS] Useless(?) asymmetry in parse_func.c

While running down loose ends in my domains-over-composite patch, I wondered why parse_func.c's FuncNameAsType() excludes composite types as possible type names. I could set up the patch to treat composite domains the same way, or not, but it wasn't obvious what to do because the point of the

Re: [HACKERS] pgbench - allow to store select results into variables

Here is a v12. Here is a v13, which is just a rebase after the documentation xml-ization. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index e509e6c..44e8896 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -818,6

Re: [HACKERS] pgbench more operators & functions

Here is a v13. No code changes, but TAP tests added to maintain pgbench coverage to green. Here is a v14, which is just a rebase after the documentation xml-ization. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index e509e6c..1f55967 100644 ---

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

The patch needs a rebase in the documentation because of the xml-ilization of the sgml doc. Thank you for the notification! Attached rebased patch. Ok. The new version works for me. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [POC] Faster processing at Gather node

On Wed, Oct 18, 2017 at 4:30 PM, Andres Freund wrote: > Hm. I'm a bit confused/surprised by that. What'd be the worst that can > happen if we don't immediately detect that the other side is detached? > At least if we only do so in the non-blocking paths, the worst that > seems

Re: [HACKERS] What is the point of setrefs.c's is_converted_whole_row_reference?

On Thu, Oct 19, 2017 at 2:56 PM, Tom Lane wrote: > AFAICS, setrefs.c's special treatment of "converted whole row references" > is completely pointless. Why aren't they just treated by the regular > "non var" code paths, thus saving code space and cycles? Here's what one of

Re: [HACKERS] 64-bit queryId?

On Fri, Oct 20, 2017 at 3:44 PM, Robert Haas wrote: > On Thu, Oct 19, 2017 at 2:11 AM, Julien Rouhaud wrote: >> I agree, and I'm perfectly fine with adding a comment around pgssHashKey. >> >> PFA a patch to warn about the danger. > > Committed a

Re: [HACKERS] 64-bit queryId?

On Thu, Oct 19, 2017 at 2:11 AM, Julien Rouhaud wrote: > I agree, and I'm perfectly fine with adding a comment around pgssHashKey. > > PFA a patch to warn about the danger. Committed a somewhat different version of this - hope you are OK with the result. -- Robert Haas

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On Tue, Oct 17, 2017 at 12:06 PM, Tomas Vondra wrote: > In general, it may be acceptable to rely on the elog() checks - which is > pretty much what the FETCH+INSERT+SHARE example I shared in the first > message of this thread does. I agree it's not particularly

Re: [HACKERS] More stats about skipped vacuums

On Tue, Oct 10, 2017 at 7:26 PM, Kyotaro HORIGUCHI wrote: > Hello. > Once in a while I am asked about table bloat. In most cases the > cause is long lasting transactions and vacuum canceling in some > cases. Whatever the case users don't have enough clues to why >

Re: [HACKERS] Cursor With_Hold Performance Workarounds/Optimization

> When we declare a cursor for a select on the mentioned big table, it takes > multiple seconds and a big temp file is created which to me seems like the > materialization took place immediately. Since you mentioned, Postgres already postponed materialization until commit operations we checked

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hello, On 2017-10-19 19:46, Andres Freund wrote: On 2017-10-19 14:36:56 +0300, Sokolov Yura wrote: > > + init_local_spin_delay(); > > The way you moved this around has the disadvantage that we now do this - > a number of writes - even in the very common case where the lwlock can > be

Re: [HACKERS] asynchronous execution

Hello. Fully-asynchronous executor needs that every node is stateful and suspendable at the time of requesting for the next tuples to underneath nodes. I tried pure push-base executor but failed. After the miserable patch upthread, I finally managed to make executor nodes suspendable using

Re: [HACKERS] Cursor With_Hold Performance Workarounds/Optimization

> > The calculations inside the loop are written in some dynamic high-level > > language and cannot easily be translated into SQL. > > You don't really have to --- PG supports functions written in non-SQL > languages. Not sure if your problem is big enough to justify developing > a new PL

Re: [HACKERS] Cursor With_Hold Performance Workarounds/Optimization

> > The calculations inside the loop are written in some dynamic high-level > > language and cannot easily be translated into SQL. > > > > ???Can you not simply create a second connection to perform the updates? That would be possibe, but I can see some problems: loop { update table1; select

Re: [HACKERS] Cursor With_Hold Performance Workarounds/Optimization

> I don't know quite how to put this, but it's not clear to me that the > difficulties in this situation are things PostgreSQL could resolve > even with much larger development resources than are currently > available. There does not seem to exist a cursor/portal/pointer semantic that can survive