> On Thu, Feb 13, 2020 at 02:25:46PM +0100, Pavel Stehule wrote:
>
> > > I like patch 0006 - filling gaps by NULLs - it fixed my objections if I
> > > remember correctly. Patch 0005 - polymorphic subscribing - I had not a
> > > idea, what is a use case? Maybe can be good to postpone this patch. I
On Fri, 14 Feb 2020 at 11:57, Amit Kapila wrote:
> On Fri, Feb 14, 2020 at 3:36 PM Thomas Munro
> wrote:
> >
> > On Fri, Feb 14, 2020 at 9:12 PM Amit Kapila
> wrote:
...
> > > Another approach that came up during an offlist discussion with Robert
> > > is that we have one dedicated worker
On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao
wrote:
> Fixed. Thanks for the review!
I think it would be safer to just report the wait event during
pg_usleep(100L) rather than putting those calls around the whole
loop. It does not seem impossible that ereport() or
CHECK_FOR_INTERRUPTS() could
Amit Kapila writes:
> I think MaxBackends will generally limit the number of different
> relations that can simultaneously extend, but maybe tables with many
> partitions might change the situation. You are right that some tests
> might suggest a good number, let Mahendra write a patch and then
On Fri, Feb 14, 2020 at 11:35 AM Michael Paquier
wrote:
> On Thu, Feb 13, 2020 at 09:05:01PM +0530, Ashutosh Bapat wrote:
> > That looks odd. Other sessions are able to see temporary tables of a
> given
> > session because they are stored in the same catalog which is accessible
> to
> > all the
Peter Eisentraut writes:
> On 2020-02-13 16:19, Tom Lane wrote:
>> According to C99 and POSIX, intptr_t should be provided by ...
>> now that we're requiring C99, can we get away with just #include'ing
>> that directly in these test files?
> I think in the past we were worried about the C
On Fri, Feb 14, 2020 at 12:30:25PM +0900, Masahiko Sawada wrote:
> * I think the function name is too generic. init_vacuum_error_callback
> or init_vacuum_errcallback is better.
> * The comment of this function is not accurate since this function is
> not only for heap vacuum but also index
On Wed, Feb 12, 2020 at 11:53 AM Tom Lane wrote:
> Yeah. I would say a couple more things:
>
> * I see no reason to think that a relation extension lock would ever
> be held long enough for noninterruptibility to be a real issue. Our
> expectations for query cancel response time are in the tens
On 2020-Feb-14, John Naylor wrote:
> One possible objection to what I wrote above is that it adds a
> different kind of special case, but in a sneaky way. Perhaps it would
> be more principled to treat it the same as oid after all. If we do
> that, it would help to add a comment that we can't
On Thu, Feb 6, 2020 at 9:19 PM Masahiko Sawada
wrote:
> This feature protects data from disk thefts but cannot protect data
> from attackers who are able to access PostgreSQL server. In this
> design application side still is responsible for managing the wrapped
> secret in order to protect it
On Fri, Feb 14, 2020 at 3:36 PM Thomas Munro wrote:
>
> On Fri, Feb 14, 2020 at 9:12 PM Amit Kapila wrote:
> > This work is to parallelize the copy command and in particular "Copy
> > from 'filename' Where ;" command.
>
> Nice project, and a great stepping stone towards parallel DML.
>
Thanks.
> On Fri, Feb 14, 2020 at 05:23:13PM +0900, Kyotaro Horiguchi wrote:
> The first attached (renamed to .txt not to confuse the cfbots) is a
> small patch that makes sure if _bt_readpage is called with the proper
> condition as written in its comment, that is, caller must have pinned
> and
Hi John,
On Fri, Feb 14, 2020 at 6:50 PM John Naylor wrote:
> On Fri, Feb 14, 2020 at 5:00 PM Amit Langote wrote:
> > I tried and think it works but not sure if that's good Perl
> > programming. See the attached.
>
> Hi Amit,
> I took this for a spin -- I just have a couple comments.
Thanks
On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
wrote:
> I have made these changes and rebased Robert’s patches but otherwise changed
> nothing. Here they are:
Thanks. Anyone else have comments? I think this is pretty
straightforward and unobjectionable work so I'm inclined to press
forward with
On Fri, Feb 14, 2020 at 6:47 PM Michael Paquier wrote:
> On Fri, Feb 14, 2020 at 06:00:05PM +0900, Amit Langote wrote:
> > On Fri, Feb 14, 2020 at 2:58 PM Amit Langote
> > wrote:
> > > On Fri, Feb 14, 2020 at 1:04 AM Tom Lane wrote:
> > > > I've been burnt by this too :-(. However, I think
On Thu, Feb 6, 2020 at 4:37 PM Cary Huang wrote:
> Since the user does not need to know the master secret key used to cipher the
> data, I don't think we should expose "pg_kmgr_unwrap("")" SQL function to
> the user at all.
> The wrapped key "" is stored in control data and it is
> On Feb 14, 2020, at 8:29 AM, David Fetter wrote:
>
> On Fri, Feb 14, 2020 at 08:16:47AM -0800, Mark Dilger wrote:
>>> On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
>>>
>>> On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
On Thu, Feb 13, 2020 at 2:38 AM Haumacher, Bernhard wrote:
> Assume the application is written in Java and sees Postgres through the
> JDBC driver:
>
> composeTransaction() {
> Connection con = getConnection(); // implicitly "begin"
> try {
>insertFrameworkLevelState(con);
>
> On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
>
> On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
>> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
>> wrote:
>>> I have made these changes and rebased Robert’s patches but
>>> otherwise changed nothing. Here they are:
>>
>>
On Fri, Feb 14, 2020 at 1:07 PM Andres Freund wrote:
> Yea, that seems possible. I'm not really sure it's needed however? As
> long as you're not teaching the locking mechanism new tricks that
> influence the wait graph, why would the deadlock detector care? That's
> quite different from the
On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
> wrote:
> > I have made these changes and rebased Robert’s patches but
> > otherwise changed nothing. Here they are:
>
> Thanks. Anyone else have comments? I think this is pretty
>
On Fri, Feb 14, 2020 at 11:40 AM Andres Freund wrote:
> IMO the right thing here is to extend lock.c so we can better represent
> whether certain types of lockmethods (& levels ?) are [not] to be
> shared.
The part that I find awkward about that is the whole thing with the
deadlock detector. The
On Fri, Feb 14, 2020 at 10:43 AM Tom Lane wrote:
> I remain unconvinced ... wouldn't both of those claims apply to any disk
> I/O request? Are we going to try to ensure that no I/O ever happens
> while holding an LWLock, and if so how? (Again, CheckpointLock is a
> counterexample, which has
On Fri, Feb 14, 2020 at 08:16:47AM -0800, Mark Dilger wrote:
> > On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
> >
> > On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
> >> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
> >> wrote:
> >>> I have made these changes and rebased
Hi,
On 2020-02-12 11:53:49 -0500, Tom Lane wrote:
> In general, if we think there are issues with LWLock, it seems to me
> we'd be better off to try to fix them, not to invent a whole new
> single-purpose lock manager that we'll have to debug and maintain.
My impression is that what's being
Hi,
On 2020-02-14 12:08:45 -0500, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 11:40 AM Andres Freund wrote:
> > IMO the right thing here is to extend lock.c so we can better represent
> > whether certain types of lockmethods (& levels ?) are [not] to be
> > shared.
>
> The part that I find
Alvaro Herrera writes:
> On 2020-Feb-14, John Naylor wrote:
>> One possible objection to what I wrote above is that it adds a
>> different kind of special case, but in a sneaky way. Perhaps it would
>> be more principled to treat it the same as oid after all. If we do
>> that, it would help to
On Fri, Feb 14, 2020 at 11:15 AM David Fetter wrote:
> One question. It might be possible to make these functions faster
> using compiler intrinsics. Would those still be available to front-end
> code?
Why not? We use the same compiler for frontend code as we do for
backend code. Possibly you
Hi,
On 2020-02-14 09:42:40 -0500, Tom Lane wrote:
> In the second place, it's ludicrous to expect that the underlying
> platform/filesystem can support an infinite number of concurrent
> file-extension operations. At some level (e.g. where disk blocks
> are handed out, or where a record of the
Andres Freund writes:
> On 2020-02-13 18:57:10 -0500, Tom Lane wrote:
>> Maybe we could decide that the time for supporting easy updates from
>> pre-9.1 is past, and just remove all the unpackaged-to-XXX scripts?
>> Maybe even remove the "FROM version" option altogether.
> Yea, that strikes me
On Fri, 14 Feb 2020 at 12:37, Robert Haas wrote:
> On Thu, Feb 13, 2020 at 2:38 AM Haumacher, Bernhard
> wrote:
> > Assume the application is written in Java and sees Postgres through the
> > JDBC driver:
> >
> > composeTransaction() {
> > Connection con = getConnection(); // implicitly
On Fri, Feb 14, 2020 at 1:04 PM Dave Cramer wrote:
> Thing is that con.commit() DOESN'T return a status code, nor does it throw an
> exception as we silently ROLLBACK here.
Why not? There's nothing keeping the driver from doing either of those
things, is there? I mean, if using libpq, you can
On Fri, 14 Feb 2020 at 13:29, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 1:04 PM Dave Cramer
> wrote:
> > Thing is that con.commit() DOESN'T return a status code, nor does it
> throw an exception as we silently ROLLBACK here.
>
> Why not? There's nothing keeping the driver from doing either
On 2020-Feb-14, Dave Cramer wrote:
> I offered to make the behaviour in the JDBC driver dependent on a
> configuration parameter
Do you mean "if con.commit() results in a rollback, then an exception is
thrown, unless the parameter XYZ is set to PQR"?
--
Álvaro Herrera
On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer wrote:
> Well now you are asking the driver to re-interpret the results in a different
> way than the server which is not what we tend to do.
>
> The server throws an error we throw an error. We really aren't in the
> business of re-interpreting the
On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> On Fri, Feb 14, 2020 at 2:08 PM Dave Cramer
> wrote:
> > Well now you are asking the driver to re-interpret the results in a
> different way than the server which is not what we tend to do.
> >
> > The server throws an error we throw an error.
On Fri, 14 Feb 2020 at 15:07, Tom Lane wrote:
> Dave Cramer writes:
> > On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
> >> I'm not trying to deny that you might find some other server behavior
> >> more convenient. You might. And, to Vik's original point, it might be
> >> more compliant
On Sun, Sep 29, 2019 at 9:24 PM Michael Paquier wrote:
>
> On Sat, Sep 28, 2019 at 10:22:28PM -0300, Alvaro Herrera wrote:
> > I always thought that create index concurrently was prevented from
> > running concurrently in a table by the ShareUpdateExclusive lock that's
> > held during the
I went ahead and registered this in the current only CF as
https://commitfest.postgresql.org/27/2454/
Alvaro: Would you like to be added as a reviewer?
James
On 2/14/20 4:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> It wouldn't be difficult to introduce a new protocol-level option that
>> prohibits RESET SESSION AUTHORIZATION; and it would also be possible
>> to introduce a new protocol message that has the same effect as RESET
>> SESSION
Chapman Flack writes:
> On 2/14/20 4:01 PM, Tom Lane wrote:
>> ... A protocol-level message
>> to set session auth could also be possible, of course.
> I'll once again whimper softly and perhaps ineffectually that an
> SQL-exposed equivalent like
> SET SESSION AUTHORIZATION foo WITH RESET
On Fri, 14 Feb 2020 at 15:19, Alvaro Herrera
wrote:
> On 2020-Feb-14, Dave Cramer wrote:
>
> > I offered to make the behaviour in the JDBC driver dependent on a
> > configuration parameter
>
> Do you mean "if con.commit() results in a rollback, then an exception is
> thrown, unless the parameter
[ Starting a new thread about this, since the old one about GUC reporting
is only marginally related to this point ... if it were more so, maybe I'd
have found it when I went looking for it yesterday ]
Robert Haas writes:
> On Tue, Nov 5, 2019 at 10:02 AM Alvaro Herrera
> wrote:
>> There's a
On Thu, Sep 19, 2019 at 5:34 AM Amit Kapila wrote:
>
> On Wed, Sep 18, 2019 at 10:25 AM Amit Kapila wrote:
> >
> > On Tue, Sep 17, 2019 at 5:48 PM James Coleman wrote:
> > >
> > > On Tue, Sep 17, 2019 at 2:21 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Let me know what you think of
Dave Cramer writes:
> On Fri, 14 Feb 2020 at 14:37, Robert Haas wrote:
>> I'm not trying to deny that you might find some other server behavior
>> more convenient. You might. And, to Vik's original point, it might be
>> more compliant with the spec, too. But since changing that would have
>> a
Hello,
We (David and I) recently observed that a Zedstore table can be considerably
bloated when we load data into it with concurrent copies. Also, we found
that
concurrent insert performance was less than desirable. This is a detailed
analysis of the extent of the problem, the cause of the
On Wed, 2020-02-12 at 21:51 -0800, Jeff Davis wrote:
> On Mon, 2020-02-10 at 15:57 -0800, Jeff Davis wrote:
> > Attaching latest version (combined logtape changes along with main
> > HashAgg patch).
>
> I ran a matrix of small performance tests to look for regressions.
I ran some more tests,
Andrew Dunstan writes:
> I also object because 20 is *my* unlucky number ...
Not sure how serious Andrew is being here, but it does open up an
important point: there are varying opinions on which numbers are unlucky.
The idea that 13 is unlucky is Western, and maybe even only common in
On Fri, Feb 14, 2020 at 4:57 PM Tom Lane wrote:
> Ashwin Agrawal writes:
> > In general, the variable LN_S is 'ln -s', however, LN_S changes to 'cp
> > -pR' if configure finds the file system does not support symbolic
> > links.
> > I was playing with 'ln' for some other reason where I symbolic
On 15/02/2020 04:07, Bryn Llewellyn wrote:
> This:
>
> select jsonb_pretty(jsonb_build_object(
> 'a'::varchar, 1.7::numeric,
> 'b'::varchar, 'dog'::varchar,
> 'c'::varchar, true::boolean
> ))
>
> allows me to express what I want. That’s a good thing. Are you saying that
> this:
>
> select
On Fri, Feb 14, 2020 at 7:16 PM Alastair Turner wrote:
>
> On Fri, 14 Feb 2020 at 11:57, Amit Kapila wrote:
>>
>> On Fri, Feb 14, 2020 at 3:36 PM Thomas Munro wrote:
>> >
>> > On Fri, Feb 14, 2020 at 9:12 PM Amit Kapila
>> > wrote:
>
> ...
>>
>> > > Another approach that came up during an
In general, the variable LN_S is 'ln -s', however, LN_S changes to 'cp
-pR' if configure finds the file system does not support symbolic
links.
I was playing with 'ln' for some other reason where I symbolic linked
it to '/bin/false'. That revealed the failure for
src/backend/Makefile. Greping for
On 02/14/20 18:43, Tom Lane wrote:
> I suppose it could be argued that that's a bug in the interpretation
> of role membership: arguably, if you're a member of some superuser
> role, that ought to give you membership in anything else. IOW, a
> superuser's implicit membership in every role isn't
Ashwin Agrawal writes:
> In general, the variable LN_S is 'ln -s', however, LN_S changes to 'cp
> -pR' if configure finds the file system does not support symbolic
> links.
> I was playing with 'ln' for some other reason where I symbolic linked
> it to '/bin/false'. That revealed the failure for
On Fri, Feb 14, 2020 at 8:12 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > I think MaxBackends will generally limit the number of different
> > relations that can simultaneously extend, but maybe tables with many
> > partitions might change the situation. You are right that some tests
> >
On Friday, February 14, 2020, Bryn Llewellyn wrote:
>
>
> select jsonb_pretty(jsonb_object(
> '{a, 17, b, "dog", c, true}'::varchar[]
> ))
>
> In other words, do the double quotes around "dog" have no effect? That
> would be a bad thing—and it would limit the usefulness of the
> jsonb_object()
On Fri, Feb 14, 2020 at 4:19 PM Tom Lane wrote:
> Not sure how serious Andrew is being here, but it does open up an
> important point: there are varying opinions on which numbers are unlucky.
> The idea that 13 is unlucky is Western, and maybe even only common in
> English-speaking countries.
I
Ashwin Agrawal writes:
> On Fri, Feb 14, 2020 at 4:57 PM Tom Lane wrote:
>> Hm. So, these oversights are certainly bugs in narrow terms. However,
>> they've all been like that for a *long* time --- the three instances
>> you found date to 2005, 2006, and 2008 according to "git blame".
>> The
Execute this:
select jsonb_pretty(jsonb_build_object(
'a'::varchar, 1.7::numeric,
'b'::varchar, 'dog'::varchar,
'c'::varchar, true::boolean
))
It produces the result that I expect:
{ +
"a": 1.7, +
"b": "dog",+
"c": true +
}
Notice that the numeric, text,
Thank you both, Vik, and David, for bing so quick to respond. All is clear now.
It seems to me that the price (giving up the ability to say explicitly what
primitive JSON values you want) is too great to pay for the benefit (being able
to build the semantic equivalent of a variadic list of
On Thu, Feb 13, 2020 at 1:34 PM Andrew Dunstan
wrote:
> I also object because 20 is *my* unlucky number ...
I don't think we're going to do this, so you don't have to worry on that score.
--
Peter Geoghegan
On 15/02/2020 03:21, Bryn Llewellyn wrote:
> Now execute this supposed functional equivalent:
>
> select jsonb_pretty(jsonb_object(
> '{a, 17, b, "dog", c, true}'::varchar[]
> ))
>
> It is meant to be a nice alternative when you want to build an object (rather
> than an array) because the
On Fri, Feb 14, 2020 at 9:13 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Wed, Feb 12, 2020 at 11:53 AM Tom Lane wrote:
>
> > That's an interesting idea, but it doesn't make the lock acquisition
> > itself interruptible, which seems pretty important to me in this case.
>
> Good point: if
This:
select jsonb_pretty(jsonb_build_object(
'a'::varchar, 1.7::numeric,
'b'::varchar, 'dog'::varchar,
'c'::varchar, true::boolean
))
allows me to express what I want. That’s a good thing. Are you saying that this:
select jsonb_pretty(jsonb_object(
'{a, 17, b, "dog", c, true}'::varchar[]
On Friday, February 14, 2020, Bryn Llewellyn wrote:
>
> The doc (“Builds a JSON object out of a text array.”) is simply too terse
> to inform an answer to this question.
>
It does presume knowledge but it precisely defines the outcome:
PostgreSQL arrays are typed and all members are of the same
I wrote:
> What I'm now thinking is that we shouldn't mess with the behavior of
> SET ROLE, as I mused about doing yesterday in [1]. It's spec-compliant,
> or close enough, so let's leave it be. On the other hand, changing the
> behavior of SET SESSION AUTHORIZATION is not constrained by spec
>
I propose this more concise coding for AddDefaultValues,
# Now fill in defaults, and note any columns that remain undefined.
foreach my $column (@$schema)
{
my $attname = $column->{name};
my $atttype = $column->{type};
#
Hi,
Patch may look as simple as this one:
https://patch-diff.githubusercontent.com/raw/postgres/postgres/pull/49.diff
Previous mention in -hackers is available at
https://postgrespro.com/list/id/cakjs1f9n-wapop5xz1dtgdpdqmzegqqk4sv2mk-zzugfc14...@mail.gmail.com
-
seems everyone overlooked that
Robert Haas writes:
> On Wed, Feb 12, 2020 at 11:53 AM Tom Lane wrote:
>> * I see no reason to think that a relation extension lock would ever
>> be held long enough for noninterruptibility to be a real issue. Our
>> expectations for query cancel response time are in the tens to
>> hundreds of
Thank you very much for the benchmarking!
A bit different topic from the latest branch..
At Sat, 8 Feb 2020 14:11:59 +0100, Tomas Vondra
wrote in
> >Yes, I've mentioned that already in one of the previous emails :) The
> >simplest way I see to achieve what we want is to do something like in
On Fri, Feb 14, 2020 at 2:58 PM Amit Langote wrote:
> On Fri, Feb 14, 2020 at 1:04 AM Tom Lane wrote:
> > I've been burnt by this too :-(. However, I think this patch is
> > completely the wrong way to go about improving this. What we should
> > be doing, now that we have all that perl code
This work is to parallelize the copy command and in particular "Copy
from 'filename' Where ;" command.
Before going into how and what portion of 'copy command' processing we
can parallelize, let us see in brief what are the top-level operations
we perform while copying from the file into a
On Fri, Feb 14, 2020 at 11:42 AM Masahiko Sawada
wrote:
>
> On Thu, 13 Feb 2020 at 13:16, Amit Kapila wrote:
> >
> > On Tue, Feb 11, 2020 at 9:13 PM Tom Lane wrote:
> > >
> > > I took a brief look through this patch. I agree with the fundamental
> > > idea that we shouldn't need to use the
> pronangs, since we need more information than what's in each pg_class
Sigh, and of course I met pg_proc.pronargs.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Em sex., 14 de fev. de 2020 às 03:13, Michael Paquier
escreveu:
> On Thu, Feb 13, 2020 at 02:22:36PM -0300, Ranier Vilela wrote:
> > I just kept it, even if I duplicated the error message, the style was
> kept
> > and in my opinion it is much more coherent and readable.
> > But your solution is
On 2020-02-13 16:19, Tom Lane wrote:
According to C99 and POSIX, intptr_t should be provided by ...
now that we're requiring C99, can we get away with just #include'ing
that directly in these test files?
I think in the past we were worried about the C library not being fully
C99. But the
čt 30. 1. 2020 v 15:21 odesílatel Pavel Stehule
napsal:
>
>
> čt 30. 1. 2020 v 15:17 odesílatel 曾文旌(义从)
> napsal:
>
>>
>>
>> > 2020年1月29日 下午9:48，Robert Haas 写道：
>> >
>> > On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从)
>> wrote:
>> >>> Opinion by Pavel
>> >>> + rel->rd_islocaltemp = true; <<<
> > > On Sat, Jun 15, 2019 at 10:02 AM Tom Lane wrote:
> > >
> > > Another reason for having the planner do this is that presumably, in
> > > an AM that's excited about this, the set of fetched columns should
> > > play into the cost estimates for the scan. I've not been paying
> > > enough
I wrote:
> + elsif ($attname eq 'relnatts')
> + {
> + ;
> + }
>
> With your patch, I get this when running
> src/include/catalog/reformat_dat_file.pl:
>
> strip_default_values: pg_class.relnatts undefined
>
> Rather than adding this one-off case to AddDefaultValues and then
> another special case
On Fri, Feb 14, 2020 at 06:00:05PM +0900, Amit Langote wrote:
> On Fri, Feb 14, 2020 at 2:58 PM Amit Langote wrote:
> > On Fri, Feb 14, 2020 at 1:04 AM Tom Lane wrote:
> > > I've been burnt by this too :-(. However, I think this patch is
> > > completely the wrong way to go about improving
On Fri, Feb 14, 2020 at 5:00 PM Amit Langote wrote:
> I tried and think it works but not sure if that's good Perl
> programming. See the attached.
Hi Amit,
I took this for a spin -- I just have a couple comments.
+ elsif ($attname eq 'relnatts')
+ {
+ ;
+ }
With your patch, I get this when
On Fri, Feb 14, 2020 at 9:12 PM Amit Kapila wrote:
> This work is to parallelize the copy command and in particular "Copy
> from 'filename' Where ;" command.
Nice project, and a great stepping stone towards parallel DML.
> The first idea is that we allocate each chunk to a worker and once the
On Sun, Feb 9, 2020 at 9:18 AM Amit Kapila wrote:
>
> It seems for this we formed a cache of max_cached_tuplebufs number of
> objects and we don't need to allocate more than that number of tuples
> of size MaxHeapTupleSize because we will anyway return that memory to
> aset.c.
>
In the approach
83 matches
Mail list logo
