> 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
> > 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 so
> > 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 interfa
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 comput
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(&delayStatus);
>
> 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
> 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 aga
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
> they have bloated tables.
>
> At
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 convenient,
> and perhaps we should
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
EnterpriseDB: http://www.
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 somewhat different version of this - hope you are O
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 Ashutosh's commit mess
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 that could happen is
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
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
--- a/doc/sr
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 +818,5
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 excl
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
> "multiplex_gather", like in the attached patch.
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() function (that wor
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 pg_dumpall behavior even after refactoring, this option
> >
19 matches
Mail list logo
