Hi.
>From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
>
>New version of builtin connection pooler fixing handling messages of extended
>protocol.
>
Here are things I've noticed.
1. Is adding guc to postgresql.conf.sample useful for users?
2. When proxy_port is a bit large (perhaps mo
I am developed my own PostgreSQL extension for learning purpose and it is
working correctly but I want to know to which components of the database is my
own extension components communicate. For example I have c code, make file sql
script, and control file after compiling the make file to which
At Tue, 12 Nov 2019 12:31:41 +0900, Michael Paquier wrote
in
> On Mon, Nov 11, 2019 at 06:28:47PM +, Ranier Vilela wrote:
> > Can anyone check this bug fix?
> >
> > +++ event_trigger.c Mon Nov 11 13:52:35 2019
> > @@ -171,7 +171,7 @@
> > HeapTuple tuple;
> > Oid
Thank you for your comments.
1. The #if ... defined(__ cplusplus) is necessary for the successful
compilation of C++ llvmjit code that uses C headers.
2. #if defined(HAVE_GSS_API_H) && !defined(GSS_DLLIMP) is necessary for the
successful link libgss.a provided by MSYS2.
3. Remember that you need t
On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote:
>
>
> Thanks Amit for your comments. Please find the updated patch which
> does not include the changes mentioned above.
>
Thanks for working on this. I have pushed your latest patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterp
On Mon, Nov 11, 2019 at 1:57 PM Amit Kapila wrote:
>
> This patch adds a few test cases to test the syntax in
> /src/test/regress/sql/drop_if_exists.sql which I think is not the best
> place to add the tests for this feature as it is primarily testing ..
> IF EXISTS .. syntax. OTOH, I am not sure
On Mon, Oct 28, 2019 at 03:42:02AM +, Smith, Peter wrote:
> From: Kyotaro Horiguchi Sent: Monday, 28 October
> 2019 1:26 PM
>> It is missing the __cplusplus case?
>
> My use cases for the macro are only in C code, so that's all I was interested
> in at this time.
> If somebody else wants to
On Tue, Oct 22, 2019 at 04:13:03PM +0530, Amit Kapila wrote:
> Hmm, but then what is your suggestion for existing code that uses {0}.
> If we reject this patch and leave the current code as it is, there is
> always a risk of some people using {0} and others using memset which
> will lead to further
On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Nov 11, 2019 at 12:59 PM Dilip Kumar wrote:
> >
> > On Mon, Nov 11, 2019 at 9:43 AM Dilip Kumar wrote:
> > >
> > > On Fri, Nov 8, 2019 at 11:49 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Yeah, I think it is difficult to ge
út 12. 11. 2019 v 1:13 odesílatel Nikita Glukhov
napsal:
> Attached 40th version of the patches.
>
>
> On 19.10.2019 18:31, Pavel Stehule wrote:
>
> This patch is still pretty big - it is about 6000 lines (without any
> documentation). I checked the standard - and this patch try to implement
>
>
On Fri, Nov 08, 2019 at 09:30:56AM +0900, Michael Paquier wrote:
> On Thu, Nov 07, 2019 at 06:01:34PM +0900, Kyotaro Horiguchi wrote:
>> Sorry, but I also vote -1 for the new function.
>
> So do I. If there are no objections, I will mark the patch as
> rejected in the CF app.
And done.
--
Michae
On Mon, Nov 11, 2019 at 05:22:32PM +0300, Nikolay Shaplov wrote:
> Here goes v3 patch with the typo fixed
Still one here in v3 of the patch:
+ * Since there are no options for patitioned tables for now, we just do
+ * validation to report incorrect option error and leave.
It looks like you are
On Sat, Nov 9, 2019 at 1:36 PM, Julien Rouhaud wrote:
> On Fri, Nov 8, 2019 at 3:31 PM Julien Rouhaud wrote:
> >
> > On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com
> > wrote:
> > >
> > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote:
> > > > > [0002 patch]
> > > > > In pgss_p
On Mon, Nov 11, 2019 at 04:25:56PM +0100, Antonin Houska wrote:
>> On Fri, Oct 04, 2019 at 12:11:11PM +0200, Antonin Houska wrote:
> + /*
> +* Update read state information.
> +*
> +* If XLogRead() is was called by ->read_page, it should have updated
> the
> +
On Tue, Nov 12, 2019 at 7:47 AM Michael Paquier wrote:
>
> On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-11, Amit Kapila wrote:
> >
> >> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier
> >> wrote:
> >>> So your suggestion would be to call GetFlushRecPtr() before
At Tue, 12 Nov 2019 11:17:26 +0900, Michael Paquier wrote
in
> On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-11, Amit Kapila wrote:
> >
> >> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier
> >> wrote:
> >>> So your suggestion would be to call GetFlushRecPtr()
On Tue, Nov 12, 2019 at 4:23 PM Thomas Munro wrote:
> On Tue, Nov 12, 2019 at 4:20 PM Kyotaro Horiguchi
> wrote:
> > At Mon, 11 Nov 2019 17:24:45 -0500, Tom Lane wrote in
> > > Although the patch seems unobjectionable as far as it goes, I'd like
> > > to understand why we didn't see the need for
On Mon, Nov 11, 2019 at 10:56:51AM -0500, Tom Lane wrote:
> This seems like it probably breaks a lot of other cases along the way.
> Why have you made all these #if tests dependent on defined(__cplusplus)?
> That's surely not specific to MSYS2. (I'm a bit bemused by the idea
> that our code compil
On Mon, Nov 11, 2019 at 06:28:47PM +, Ranier Vilela wrote:
> Can anyone check this bug fix?
>
> +++ event_trigger.c Mon Nov 11 13:52:35 2019
> @@ -171,7 +171,7 @@
> HeapTuple tuple;
> Oid funcoid;
> Oid funcrettype;
>
On Tue, Nov 12, 2019 at 4:20 PM Kyotaro Horiguchi
wrote:
> At Mon, 11 Nov 2019 17:24:45 -0500, Tom Lane wrote in
> > Although the patch seems unobjectionable as far as it goes, I'd like
> > to understand why we didn't see the need for it long since. Is there
> > another call to ExecParallelHashC
On Mon, Nov 11, 2019 at 09:02:01AM +0900, Michael Paquier wrote:
> Thanks for your input, Tom. This matches with my opinion about this
> thread and this patch.
And switched the CF entry of the patch as rejected.
--
Michael
signature.asc
Description: PGP signature
At Mon, 11 Nov 2019 17:24:45 -0500, Tom Lane wrote in
> Although the patch seems unobjectionable as far as it goes, I'd like
> to understand why we didn't see the need for it long since. Is there
> another call to ExecParallelHashCloseBatchAccessors somewhere, and
> if so, is that one wrongly pl
On 10/20/19 14:47, Tom Lane wrote:
> Chapman Flack writes:
>> data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
>> boundaries."
>> ... while the documentation for pg_type has:
>> "c = char alignment, i.e., no alignment needed.
>> s = short alignment (2 bytes on most m
At Mon, 11 Nov 2019 17:24:45 -0500, Tom Lane wrote in
> Thomas Munro writes:
> > On Tue, Nov 12, 2019 at 1:24 AM Kyotaro Horiguchi
> > wrote:
> >> Hello. While looking a patch, I found that PHJ sometimes complains for
> >> file leaks if accompanied by LIMIT.
>
> > Thanks for the patch! Yeah,
On 09/29/19 20:13, Chapman Flack wrote:
> From looking around the code, I've made these tentative observations
> about TupleDescs:
>
> 1. If the TupleDesc was obtained straight from the relcache for some
>relation, then all of its attributes should have nonzero attrelid
>identifying that r
On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-11, Amit Kapila wrote:
>
>> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
>>> So your suggestion would be to call GetFlushRecPtr() before the first
>>> check on RecentFlushPtr and before entering the loop?
>>
On Mon, 11 Nov 2019 at 19:29, Amit Kapila wrote:
>
> On Mon, Nov 11, 2019 at 12:26 PM Masahiko Sawada
> wrote:
> >
> > On Mon, 11 Nov 2019 at 15:06, Dilip Kumar wrote:
> > >
> > > On Mon, Nov 11, 2019 at 9:57 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > Good point. gin and bloom do a certain
On Mon, Nov 11, 2019 at 09:11:35PM +0100, Laurenz Albe wrote:
> Will this work on Windows?
> A quick web search seems to indicate that Windows has no statfs(2).
It won't. We are actually discussing the compatibility aspects and
the minimal data set we could grab in a different part of the thread.
On Sat, Nov 09, 2019 at 02:33:49PM +0100, Christoph Moench-Tegeder wrote:
> "The statfs() system call first appeared in 4.4BSD." (from the statfs(2)
> manpage on FreeBSD). struct statfs differs between Linux and BSD, but
> is "close enough" for this, the fields from the original patch are
> present
On 11/11/19 2:33 PM, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that function is not
On Mon, Nov 11, 2019 at 9:49 PM Peter Eisentraut
wrote:
> On 2019-11-11 08:59, Amit Langote wrote:
> > On Fri, Nov 8, 2019 at 1:27 PM Amit Langote wrote:
> >> Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
> >> implements the feature.
> >
> > 0002 didn't contain necessary
On Mon, Nov 11, 2019 at 04:43:18PM +0100, Gilles Darold wrote:
> Hi Michael, it looks that a separate test is not required at least for
> this test. Here is a patch that enable the test in
> contrib/postgres_fdw/, expected output:
Indeed, thanks for looking. I thought that the callback was called
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that function is not
immediately obvious, and where to add a
Thomas Munro writes:
> On Tue, Nov 12, 2019 at 1:24 AM Kyotaro Horiguchi
> wrote:
>> Hello. While looking a patch, I found that PHJ sometimes complains for
>> file leaks if accompanied by LIMIT.
> Thanks for the patch! Yeah, this seems correct, but I'd like to think
> about it some more before
On Tue, Nov 12, 2019 at 1:24 AM Kyotaro Horiguchi
wrote:
> Hello. While looking a patch, I found that PHJ sometimes complains for
> file leaks if accompanied by LIMIT.
Oops.
> Repro is very simple:
>
> create table t as (select a, a as b from generate_series(0, 99) a);
> analyze t;
> select
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and collation OIDs embedded in such a node.
This can be demonstrated to be a problem by the attached script,
which will end up with a "cache lookup failed for
On 11/11/19 11:28 AM, Andrew Dunstan wrote:
On 11/11/19 1:27 PM, Mark Dilger wrote:
On 11/11/19 8:48 AM, Andrew Dunstan wrote:
On 11/9/19 8:25 AM, Andrew Dunstan wrote:
OK, I agree that we're getting rather baroque here. I could go with
your
suggestion of YA function, or possibly a solu
(BTW another small issue in the patch is the comments in gram.y that
talk about ONLY being a reserved word about the SQL:2008 syntax; ISTM
that that comment should now mention both ONLY as well as WITH being
fully reserved words.)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Post
On Mon, 11 Nov 2019 at 15:17, Alvaro Herrera
wrote:
> On 2019-Nov-11, Dave Cramer wrote:
>
> > Following 2 patches address Dmitry's concern and check for compatibility.
>
> Please resend the whole patchset, so that the patch tester can verify
> the series. (Doing it helps humans, too).
>
>
Attac
On 2019-Nov-11, Dave Cramer wrote:
> Following 2 patches address Dmitry's concern and check for compatibility.
Please resend the whole patchset, so that the patch tester can verify
the series. (Doing it helps humans, too).
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQ
On Wed, Nov 6, 2019 at 9:31 PM Paul A Jungwirth
wrote:
> I've also added some progress on adding FOR PORTION OF to UPDATE and DELETE
> (mostly UPDATE).
I could use some guidance on where in the query-processing pipeline I
should implement some things here. Basically if you say
UPDATE t FOR P
On Fri, 2019-11-08 at 14:24 +0100, Christoph Berg wrote:
> Monitoring the available disk space is the topmost thing on the
> priority for PostgreSQL operation, yet this metric is not available
> from the SQL level.
>
> The attached patch implements a function pg_tablespace_statfs(tblspc)
> to repo
On Sat, 2019-11-09 at 21:38 +0100, Daniel Gustafsson wrote:
> I took a look at this patch again today for a review of the latest version.
> While I still think it's a potential footgun due to read-only FDW's, I can see
> usecases for having it so I'm mildly +1 on adding it.
I don't feel good about
Robert Haas wrote:
> On Sat, Nov 2, 2019 at 8:23 AM Antonin Houska wrote:
> > Change to hint bits does not result in LSN change in the case I described
> > here
> >
> > https://www.postgresql.org/message-id/28452.1572443058%40antos
> >
> > but I consider this a bug (BTW, I discovered this probl
> On Mon, Nov 11, 2019 at 11:15:45AM -0500, Dave Cramer wrote:
> On Fri, 8 Nov 2019 at 11:20, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > > On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote:
> > >
> > > See attached
> >
> > --- a/src/backend/replication/logical/worker.c
> >
On Mon, 11 Nov 2019 at 12:07, Dave Cramer wrote:
>
>
> On Mon, 11 Nov 2019 at 12:04, Alvaro Herrera
> wrote:
>
>> On 2019-Nov-11, Dave Cramer wrote:
>>
>> > Previously someone mentioned that we need to confirm whether the two
>> > servers are compatible for binary or not.
>> >
>> > Checking to m
On 11/11/19 1:27 PM, Mark Dilger wrote:
>
>
> On 11/11/19 8:48 AM, Andrew Dunstan wrote:
>>
>> On 11/9/19 8:25 AM, Andrew Dunstan wrote:
>>> OK, I agree that we're getting rather baroque here. I could go with
>>> your
>>> suggestion of YA function, or possibly a solution that simple passes
>>> an
On 11/7/19 12:30 PM, Andrew Dunstan wrote:
> On 11/4/19 4:43 PM, Thomas Munro wrote:
>> It looks like the new declarations in libpq-be.h are ifdef'd out in a
>> non-USE_SSL build, but then we still try to build the new test module
>> and it fails:
>>
>> https://ci.appveyor.com/project/postgresql-c
Hi,
On 2019-09-06 10:25:22 -0400, Robert Haas wrote:
> On Thu, Sep 5, 2019 at 5:32 PM Andres Freund wrote:
> > On 2019-09-05 14:50:50 -0400, Robert Haas wrote:
> > > The best way that I've been able to come up with to enforce this rule
> > > after a little bit of thought is to add Assert(IsTransa
Hi,
Can anyone check this bug fix?
Thanks.
Ranier Vilela
--- \dll\postgresql-12.0\a\backend\commands\event_trigger.c Mon Sep 30
17:06:55 2019
+++ event_trigger.c Mon Nov 11 13:52:35 2019
@@ -171,7 +171,7 @@
HeapTuple tuple;
Oid funcoid;
On 11/11/19 8:48 AM, Andrew Dunstan wrote:
On 11/9/19 8:25 AM, Andrew Dunstan wrote:
OK, I agree that we're getting rather baroque here. I could go with your
suggestion of YA function, or possibly a solution that simple passes any
extra arguments straight through to IPC::Run::run(), e.g.
co
Hi Tomas,
On 11/10/19 4:18 PM, Tomas Vondra wrote:
I've looked at the patch again - in general it seems in pretty good
shape, all the issues I found are mostly minor.
Firstly, I'd like to point out that not all of the things I complained
about in my 2019/06/23 review got addressed. Those were m
On Sat, Nov 2, 2019 at 8:23 AM Antonin Houska wrote:
> Change to hint bits does not result in LSN change in the case I described here
>
> https://www.postgresql.org/message-id/28452.1572443058%40antos
>
> but I consider this a bug (BTW, I discovered this problem when thinking about
> the use of LS
On Sun, Nov 10, 2019 at 05:45:08PM +0800, Craig Ringer wrote:
> On Sun, 10 Nov 2019 at 13:42, Tom Lane wrote:
>
> > Andres Freund writes:
> > > On 2019-11-08 14:49:25 +0800, Craig Ringer wrote:
> > >> I recently found the need to pretty-print the contents of pg_locks. So
> > >> here's a little h
Konstantin Knizhnik writes:
>> čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi
>> mailto:horikyota@gmail.com>> napsal:
>>> I might be too worrying, but maybe we should write the function in
>>> white-listed way, that is, expr_needs_snapshot returns false only if
>>> the whole tree consist
On Mon, 11 Nov 2019 at 12:04, Alvaro Herrera
wrote:
> On 2019-Nov-11, Dave Cramer wrote:
>
> > Previously someone mentioned that we need to confirm whether the two
> > servers are compatible for binary or not.
> >
> > Checking to make sure the two servers have the same endianness is
> obvious.
>
On 2019-Nov-11, Dave Cramer wrote:
> Previously someone mentioned that we need to confirm whether the two
> servers are compatible for binary or not.
>
> Checking to make sure the two servers have the same endianness is obvious.
> Sizeof int, long, float, double, timestamp (float/int) at a minimu
On 2019-Nov-11, Amit Kapila wrote:
> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
> > So your suggestion would be to call GetFlushRecPtr() before the first
> > check on RecentFlushPtr and before entering the loop?
>
> No. What I meant was to keep the current code as-is and have an
>
On 11/9/19 8:25 AM, Andrew Dunstan wrote:
> OK, I agree that we're getting rather baroque here. I could go with your
> suggestion of YA function, or possibly a solution that simple passes any
> extra arguments straight through to IPC::Run::run(), e.g.
>
> command_fails_like(
> [ 'pg_dump',
On Fri, 8 Nov 2019 at 11:20, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote:
> >
> > See attached
>
> --- a/src/backend/replication/logical/worker.c
> +++ b/src/backend/replication/logical/worker.c
> @@ -1779,6 +1779,7 @@ Ap
> 8 нояб. 2019 г., в 0:26, Bruce Momjian написал(а):
>
> First, notice "only", which was missing from the later sentence:
>
>For INSERT and UPDATE
>operations [only], the trigger may modify the
>NEW row before returning it.
>
> which I have now added with my applied patch to all s
=?UTF-8?B?0JPRg9GA0LDQvCDQlNGD0LrQsA==?= writes:
> I made a patch fixing build and install problems under MSYS2, including
> llvmjit.
This seems like it probably breaks a lot of other cases along the way.
Why have you made all these #if tests dependent on defined(__cplusplus)?
That's surely not s
Euler Taveira writes:
> Em dom., 10 de nov. de 2019 às 18:29, Justin Pryzby
> escreveu:
>> We have some very wide tables (historically, up to 1600 columns ; this is
>> improved now, but sometimes still several hundred, with numerous pages output
>> to psql pager). Is is reasonable to suggest add
Le 09/11/2019 à 02:22, Michael Paquier a écrit :
> On Fri, Nov 08, 2019 at 10:19:01AM +0100, Gilles Darold wrote:
>> I don't think so. The support or not of 2PC is on foreign data wrapper
>> side. In postgres_fdw contrib the error for use with 2PC is not part of
>> the test but it will be thrown an
Michael Paquier wrote:
> On Fri, Oct 04, 2019 at 12:11:11PM +0200, Antonin Houska wrote:
> > This is the next version.
>
> So... These are the two last bits to look at, reducing a bit the code
> size:
> 5 files changed, 396 insertions(+), 419 deletions(-)
>
> And what this patch set does is to
On 08.11.2019 18:06, 曾文旌(义从) wrote:
My comments for global_private_temp-4.patch
Thank you very much for inspecting my patch.
good side:
1 Lots of index type on GTT. I think we need support for all kinds of
indexes.
2 serial column on GTT.
3 INHERITS GTT.
4 PARTITION GTT.
I didn't choose
Looking at this patch again. (Attached v13 fixes a typo in ruleutils,
fixes a bogus edit in the SGML docs plus minor rewording, and is rebased
to current master).
First, I noticed that there's a significant unanswered issue from Andrew
Gierth about this using a completely different mechanism, nam
Yet another version of my GTT patch addressing issues reported by
曾文旌(义从)
* Bug in TRUNCATE is fixed,
* ON COMMIT DELETE ROWS option is supported
* ALTER TABLE is correctly handled
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git
ne 10. 11. 2019 v 7:35 odesílatel Pavel Stehule
napsal:
>
>
> so 9. 11. 2019 v 21:34 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > four years ago Marko Tiikkaja send a patch for numeric_trim functions.
>> This
>> > functions removed ending zeroes from numeric value. This is useful
Alright, as usual life got in the way. I've attached a new version of
the patch with pgindent changes.
> What do you think about writing patch for ALTER TYPE?
I'd rather not :$
> 1) Write migration script, which directly updates pg_type.
This sounds like the best option right now, if we don't wan
On Mon, Nov 11, 2019 at 8:51 AM Peter Eisentraut
wrote:
> Compared to the previous patch (v7) where the API just had a "use this
> AM for TOAST" field and the other extreme of pushing TOAST entirely
> inside the heap AM, this seems like the worst of both worlds, with the
> maximum additional compl
В письме от среда, 23 октября 2019 г. 11:59:45 MSK пользователь Amit Langote
написал:
> Sorry for the late reply.
Same apologies from my side. Get decent time-slot for postgres dev only now.
> I looked atthe v2 patch and noticed a typo:
>
> + * Binary representation of relation options fo
On 2019-11-08 17:59, Robert Haas wrote:
On Wed, Nov 6, 2019 at 12:00 PM Andres Freund wrote:
I'd like an AM to have the *option* of implementing something better, or
at least go in the direction of making that possible.
OK. Could you see what you think of the attached patches? 0001 does
some
On Fri, Sep 20, 2019 at 4:16 PM Alexey Kondratov
wrote:
>
> First of all, there is definitely a problem with grammar. In docs ERROR
> is defined as option and
>
> COPY test FROM '/path/to/copy-test-simple.csv' ERROR -1;
>
> works just fine, but if modern 'WITH (...)' syntax is used:
>
> COPY test
On 2019-11-11 08:59, Amit Langote wrote:
On Fri, Nov 8, 2019 at 1:27 PM Amit Langote wrote:
Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
implements the feature.
0002 didn't contain necessary pg_dump changes, which fixed in the
attached new version.
That looks more
On Mon, Nov 11, 2019 at 5:14 PM Dilip Kumar wrote:
>
> On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila wrote:
> >
> > ..
> > > I have tested the same with some other workload(test file attached).
> > > I can see the same behaviour with this workload as well that with the
> > > patch 4 the distributio
Hello. While looking a patch, I found that PHJ sometimes complains for
file leaks if accompanied by LIMIT.
Repro is very simple:
create table t as (select a, a as b from generate_series(0, 99) a);
analyze t;
select t.a from t join t t2 on (t.a = t2.a) limit 1;
Once in several (or dozen of) t
On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Nov 11, 2019 at 12:59 PM Dilip Kumar wrote:
> >
> > On Mon, Nov 11, 2019 at 9:43 AM Dilip Kumar wrote:
> > >
> > > On Fri, Nov 8, 2019 at 11:49 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Yeah, I think it is difficult to ge
On Mon, Nov 11, 2019 at 2:53 PM Mahendra Singh wrote:
>
>
> For small indexes also, we gained some performance by parallel vacuum.
>
Thanks for doing all these tests. It is clear with this and previous
tests that this patch has benefit in wide variety of cases. However,
we should try to see som
Hi hackers.
I made a patch fixing build and install problems under MSYS2, including
llvmjit.
I have tested this in my environment and it works, of course need more
extensive testing.
Attached is a patch that fixes it. Tag REL_11_5. Easy to adapt for other
versions.
--
Best regards.
Guram Duka.
On Mon, Nov 11, 2019 at 12:59 PM Dilip Kumar wrote:
>
> On Mon, Nov 11, 2019 at 9:43 AM Dilip Kumar wrote:
> >
> > On Fri, Nov 8, 2019 at 11:49 AM Amit Kapila wrote:
> > >
> > >
> > > Yeah, I think it is difficult to get the exact balance, but we can try
> > > to be as close as possible. We can
On Mon, Nov 11, 2019 at 12:26 PM Masahiko Sawada
wrote:
>
> On Mon, 11 Nov 2019 at 15:06, Dilip Kumar wrote:
> >
> > On Mon, Nov 11, 2019 at 9:57 AM Masahiko Sawada
> > wrote:
> > >
> > > Good point. gin and bloom do a certain heavy work during cleanup and
> > > during bulkdelete as you mentione
Hi All,
I did some performance testing with the help of Dilip to test normal vacuum
and parallel vacuum. Below is the test summary-
*Configuration settings:*
autovacuum = off
shared_buffers = 2GB
max_parallel_maintenance_workers = 6
*Test 1: (*table has 4 index on all tuples and deleting alterna
On Sat, 9 Nov 2019 at 12:52, Andreas Karlsson wrote:
> On 11/8/19 2:52 PM, Rafia Sabih wrote:
> > Now, my question is shouldn't we always use this list in sorted order,
> > in other words can there be scenarios where such a sorting will not
> > help? I am talking about only the cases where the li
Michael Paquier wrote:
> Does something like the attached patch make sense? Reviews are
> welcome.
This looks good to me.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
On Tue, Oct 29, 2019 at 12:37 PM Masahiko Sawada wrote:
> I realized that v31-0006 patch doesn't work fine so I've attached the
> updated version patch that also incorporated some comments I got so
> far. Sorry for the inconvenience. I'll apply your 0001 patch and also
> test the total delay time.
On Wed, Aug 21, 2019 at 01:59:00PM -0700, Melanie Plageman wrote:
> So, what should we do about this? Do you agree that the "controller_show"
> step would be a problem?
Andres, it seems to me that this is waiting some input from you.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 11, 2019 at 06:30:22PM +0200, Julien Rouhaud wrote:
> The thing is that pg_stat_statements assigns a 0 queryid in the
> post_parse_analyze_hook to recognize utility statements and avoid
> tracking instrumentation twice in case of utility statements, and then
> compute a queryid base on
On Tue, Aug 06, 2019 at 11:24:46AM +0900, Michael Paquier wrote:
> A comment in heap_multi_insert() needs to be updated because it
> becomes the case with your patch:
> /*
> * We don't use heap_multi_insert for catalog tuples yet, but
> * better be prepared...
> */
>
> There
On Mon, Nov 11, 2019 at 8:45 AM Amit Kapila wrote:
>
> On Fri, Nov 8, 2019 at 4:57 PM Pavel Stehule wrote:
> >
> > I check it now - it has sense. the described switch can protect users
> > against useless client killing.
> >
>
> I have committed that patch. Please find the rebased patch attache
Hi Hackers,
Table AM routine already provided two custom functions to fetch sample
blocks and sample tuples,
however, the total blocks the ANALYZE can scan are still restricted to the
number of physical blocks
in a table, this doesn't work well for storages which organize blocks in
different ways
91 matches
Mail list logo
