Bonjour Michaël,
Yep, I will try for this week.
Please note that for now I have marked the patch as returned with
feedback as the CF is ending.
Ok.
I have looked quickly at it, but I'm not sure that there is an agreement
about what should be done precisely, so the feedback is not clearly
On Thu, Jul 25, 2019 at 8:45 PM Pavel Stehule wrote:
> čt 25. 7. 2019 v 5:11 odesílatel Tom Lane napsal:
>> Pavel Stehule writes:
>> > [ drop-database-force-20190708.patch ]
>>
>> I took a brief look at this, but I don't think it's really close to
>> being committable.
Hi Pavel,
The concept se
Hi Michael,
> I will further check if by mistake any further commits have removed
> > references to assignments from float8in_internal_opt_error(),
> > evaluate it, and set out a patch.
>
> Thanks, Jeevan!
>
Here is a patch that takes care of addressing the flag issue including
pg_lsn_in_internal
Greetings, Robert.
You wrote 2019-08-01, 07:30:
> On Thu, Aug 1, 2019 at 12:10 AM Thomas Munro wrote:
> Hi all,
> CF1 officially ends in about 8 hours, when August arrives on the
> volcanic islands of Howard and Baker, according to CURRENT_TIMESTAMP
> AT TIME ZONE '+12'. I'll probably
On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
> 2019年8月1日(木) 1:41 Tom Lane :
> >
> > Robert Haas writes:
> > > Yeah, but I have to admit that this whole design makes me kinda
> > > uncomfortable. Every time somebody comes up with a new figure of
> > > merit, it increases not only the numbe
On Tue, Jul 30, 2019 at 5:58 PM Andres Freund wrote:
> > +#include "c.h"
>
> Hm?
Heh.
> > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
>
> Hm, I'm not really sure that this does that much. Especially when the
> call is via a function in the same translation unit.
Yeah, I wondered
On 01.08.2019 6:10, Craig Ringer wrote:
3. It is not possible to use temporary tables at replica.
For physical replicas, yes.
Yes, definitely logical replicas (for example our PgPro-EE multimaster
based on logical replication) do not suffer from this problem.
But in case of multimaste
On Wed, Jun 26, 2019 at 6:38 AM Andres Freund wrote:
> On 2019-06-20 09:30:34 +0200, Peter Eisentraut wrote:
> > I'm looking for feedback from those who have worked on tableam and
> > storage manager to see what the right interfaces are or whether some new
> > interfaces might perhaps be appropria
On Thu, Aug 01, 2019 at 12:39:26PM +0530, Jeevan Ladhe wrote:
> Here is a patch that takes care of addressing the flag issue including
> pg_lsn_in_internal() and others.
Your original patch for pg_lsn_in_internal() was right IMO, and the
new one is not. In the numeric and float code paths, we hav
On Wed, Jul 31, 2019 at 4:24 AM Tom Lane wrote:
> Takuma Hoshiai writes:
> > [ fix_to_reg_v2.patch ]
>
> I took a quick look through this patch. I'm on board with the goal
> of not having schema-access violations throw an error in these
> functions, but the implementation feels pretty ugly and b
On Thu, Aug 01, 2019 at 09:00:41AM +0200, Fabien COELHO wrote:
> I have looked quickly at it, but I'm not sure that there is an agreement
> about what should be done precisely, so the feedback is not clearly
> actionable.
Per the latest trends, it seems that the input of Andres was kind of
the mos
On Mon, Jul 8, 2019 at 2:01 AM Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> rebased patch attached, no functionality changes
>
> > I poked at this a bit, and soon found that it fails check-world,
> > because the isolationtester binary is built with an rpath that
> > only works if
Hello.
At Thu, 1 Aug 2019 00:15:48 +, "Jamison, Kirk"
wrote in
> The patch does not apply anymore.
> In addition to the whitespace detected,
> kindly rebase the patch as there were changes from recent commits
> in the following files:
>src/backend/commands/analyze.c
>src/bin
On Wed, Jul 24, 2019 at 5:13 PM Paul A Jungwirth
wrote:
> On Tue, Jul 23, 2019 at 3:32 PM Alvaro Herrera
> wrote:
> > Just checking if you've had a chance to make progress on this.
>
> Not a lot. :-) But I should have more time for it the next few weeks
> than I did the last few. ...
Hi Paul,
Hi Michael,
On Thu, Aug 1, 2019 at 1:51 PM Michael Paquier wrote:
> On Thu, Aug 01, 2019 at 12:39:26PM +0530, Jeevan Ladhe wrote:
> > Here is a patch that takes care of addressing the flag issue including
> > pg_lsn_in_internal() and others.
>
> Your original patch for pg_lsn_in_internal() was r
On Thu, 1 Aug 2019 20:21:57 +1200
Thomas Munro wrote:
> On Wed, Jul 31, 2019 at 4:24 AM Tom Lane wrote:
> > Takuma Hoshiai writes:
> > > [ fix_to_reg_v2.patch ]
> >
> > I took a quick look through this patch. I'm on board with the goal
> > of not having schema-access violations throw an error
On Tue, Jul 23, 2019 at 4:51 PM Tatsuro Yamada
wrote:
> Attached v4 patch file only includes this fix.
Hello all,
I've moved this to the September CF, where it is in "Needs review" state.
Thanks,
--
Thomas Munro
https://enterprisedb.com
On Mon, Jul 29, 2019 at 10:40 PM Tom Lane wrote:
>
> John Naylor writes:
>
> > The lexer returns UCONST from xus and UIDENT from xui. The grammar has
> > rules that are effectively:
>
> > SCONST { do nothing}
> > | UCONST { esc char is backslash }
> > | UCONST UESCAPE SCONST { esc char is from $3
On Wed, Jul 31, 2019 at 3:13 AM Daniel Gustafsson wrote:
> > On 27 Jul 2019, at 08:42, Peter Eisentraut
> > wrote:
> > I have committed 0002, 0003, and 0004.
>
> Thanks!
>
> > The implementation in 0001 (Only allow upgrades by the same exact
> > version new bindir) has a problem. It compares (n
On Thu, Aug 1, 2019 at 8:41 PM Takuma Hoshiai wrote:
> On Thu, 1 Aug 2019 20:21:57 +1200
> Thomas Munro wrote:
> > Based on the above review, I have set this to 'Returned with
> > feedback'. If you plan to produce a new patch in time for the next
> > Commitfest in September, please let me know v
On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule wrote:
> pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal:
>> I wrote:
>> > TBH, I don't like this proposal one bit. As far as I can see, the idea
>> > is to let a function's support function redefine the function's declared
>> > argument and result
On Tue, Jul 30, 2019 at 6:42 PM Michael Paquier wrote:
> On Mon, Jul 01, 2019 at 02:33:39PM +0300, Sergei Kornilov wrote:
> > Updated version attached. Merge conflict was about tests count in
> > 001_stream_rep.pl. Nothing else was changed. My approach can be
> > still incorrect, any redesign idea
> I'm not sure we're any closer to a meeting of the minds on whether
> consulting zone[1970].tab is a good thing to do, but we got an actual
> user complaint[1] about how "localtime" should not be a preferred
> spelling. So I want to go ahead and insert the discussed anti-preference
> against "loc
On Thu, Aug 01, 2019 at 02:10:08PM +0530, Jeevan Ladhe wrote:
> The only thing is that, if the caller cares about the error during
> the parsing or not.
That's where the root of the problem is. We should really make things
so as the caller of this routine cares about errors. With your patch
a ca
On Sat, Apr 13, 2019 at 1:12 AM Alvaro Herrera wrote:
> I'm inclined to reject this patch.
On Fri, Jul 5, 2019 at 6:47 PM Peter Eisentraut
wrote:
> But you're not really supposed to use it for multiple queries or
> multiple result sets anyway. There are other functions for this.
>
> If a source
On Thu, Aug 01, 2019 at 09:06:59PM +1200, Thomas Munro wrote:
> Unfortunately this comes right that the end of the CF, but the good
> news is that there is another one just around the corner. Moved to
> September.
Moving it to the next CF is fine, thanks. The author had no time to
reply since my
2019年8月1日(木) 16:19 Richard Guo :
>
> On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
>>
>> 2019年8月1日(木) 1:41 Tom Lane :
>> >
>> > Robert Haas writes:
>> > > Yeah, but I have to admit that this whole design makes me kinda
>> > > uncomfortable. Every time somebody comes up with a new figure of
Hi,
In the undo system, we use full-transaction-id for transactions. For
rollback of prepared transactions, we were planning to use
FullTransactionId by combining TransactionId and epoch, but as
suggested by multiple people in that email chain [1][2], the better
idea is to store Full-transactioni
Michaël-san,
I have looked quickly at it, but I'm not sure that there is an agreement
about what should be done precisely, so the feedback is not clearly
actionable.
Per the latest trends, it seems that the input of Andres was kind of
the most interesting pieces.
Yes, definitely. I understo
Hello,
I attached one example of a partitioned table with multi column partition key.
I also attached the output.
Disabling the hash_join is not really necessary, it just shows the more drastic
result in the case of low work_mem.
Comparing the first and the second query I was surprised to see t
Amit-san,
On Thu, Aug 1, 2019 at 10:33 AM Amit Langote wrote:
> On Wed, Jul 31, 2019 at 9:04 PM Etsuro Fujita wrote:
> > On Wed, Jul 31, 2019 at 5:05 PM Amit Langote
> > wrote:
> > > On Tue, Jul 30, 2019 at 4:20 PM Amit Langote
> > > wrote:
> > > > On Sat, Jul 20, 2019 at 1:52 AM Andres Freu
On Sat, Jul 13, 2019 at 2:14 AM Nikolay Shaplov wrote:
> Here goes an updated version.
On Sat, Jul 20, 2019 at 8:21 PM Dent John wrote:
> [review]
On Sun, Jul 28, 2019 at 5:38 AM Tomas Vondra
wrote:
> [review]
Hi Nikolay,
Looks like some good actionable feedback. I've moved this patch to
Se
Hi,
As we are at the end of this CF and there is still discussions about whether we
should revert log_statement_sample_limit and log_statement_sample_rate, or try
to fix it in v12.
I moved this patch to next commit fest and change status from "ready for
commiter" to "need review". I hope I didn't
On Wed, Jul 31, 2019 at 1:33 PM Michael Paquier wrote:
> On Tue, Jul 30, 2019 at 04:44:11PM -0400, Tom Lane wrote:
> > We do not test \h output in any existing regression test, and we're
> > not going to start doing so in this one. For one thing, the expected
> > URL would break every time we for
On Tue, Jul 30, 2019 at 6:27 AM Tom Lane wrote:
> Chris Travers writes:
> > Here's a new patch. No rush on it. I am moving it to next commitfest
> > anyway because as code documentation I think this is a low priority late in
> > the release cycle.
> > The changes mostly address Andres's feedba
Takeshi-san,
I am sorry for late response - I just waited new version of the patch
from you for review.
I read your last proposal and it seems to be very reasonable.
From my point of view we can not reach acceptable level of performance
if we do not have local cache at all.
So, as you propose
On Thu, Aug 01, 2019 at 11:47:46AM +0200, Adrien Nayrat wrote:
Hi,
As we are at the end of this CF and there is still discussions about whether we
should revert log_statement_sample_limit and log_statement_sample_rate, or try
to fix it in v12.
I moved this patch to next commit fest and change st
On Sun, Jun 23, 2019 at 7:34 AM Corey Huinker wrote:
>> > So what is the uptake on implementing this at the server side, ie.
>> > DESCRIBE?
>>
>> I'm pretty skeptical of this idea, unless you are willing to throw
>> away at least one and possibly both of the following goals:
It seems this topic i
Hello
> It has been some time, and I am finally catching up with this patch.
Thank you!
> +
> + WAL receiver will be restarted after primary_slot_name
> + was changed.
>
> The sentence sounds strange. Here is a suggestion:
> The WAL receiver is restarted after an update of primary_sl
On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro wrote:
>
> On Wed, Jul 31, 2019 at 5:28 AM Tom Lane wrote:
> > Meanwhile, I looked at the v3 patch, and it seems like it might not be
> > too far from committable. I think we should *not* let this get bogged
> > down in questions of whether EXPLAIN can
On Wed, Jul 31, 2019 at 1:01 AM Ibrar Ahmed wrote:
> I have rebased the patch to master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012)
> and fixed some compilation warning. Now I am reviewing the actual code.
Thanks for doing that Ibrar. I think the right status for this CF
entry is now: Needs rev
On Thu, Aug 01, 2019 at 06:28:08PM +0900, Kohei KaiGai wrote:
2019年8月1日(木) 16:19 Richard Guo :
On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
2019年8月1日(木) 1:41 Tom Lane :
>
> Robert Haas writes:
> > Yeah, but I have to admit that this whole design makes me kinda
> > uncomfortable. Ever
On Thu, Aug 01, 2019 at 05:25:31PM +1200, Thomas Munro wrote:
On Thu, Aug 1, 2019 at 12:16 PM Jamison, Kirk wrote:
> On Saturday, July 27, 2019 7:06 AM(GMT+9), Tomas Vondra wrote:
> > On Fri, Jul 26, 2019 at 07:03:41AM +, Jamison, Kirk wrote:
> > >Overall, the patch is almost already in goo
On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan
wrote:
> On 7/23/19 6:48 PM, Nikita Glukhov wrote:
> > Some concrete pieces of review:
> >> +
> >> +FF1
> >> +decisecond (0-9)
> >> +
> >>
> >> Let's not use such weird terms as "deciseconds". We could say
> >> "fraction
Amit-san,
On Wed, Jul 31, 2019 at 2:47 PM Amit Langote wrote:
> On Tue, Jul 30, 2019 at 6:00 PM Etsuro Fujita wrote:
> > On Fri, Jul 19, 2019 at 10:44 PM Robert Haas wrote:
> > > I don't know whether partition_bounds_merge() is well-implemented; I
> > > haven't looked.
> >
> > My concern about
On Thu, Aug 1, 2019 at 12:13 PM Julien Rouhaud wrote:
>
> On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro wrote:
> >
> > On Wed, Jul 31, 2019 at 5:28 AM Tom Lane wrote:
> > > Meanwhile, I looked at the v3 patch, and it seems like it might not be
> > > too far from committable. I think we should *no
On Tue, Feb 26, 2019 at 5:41 AM Corey Huinker wrote:
>> In order to avoid per-row calls of the constraint trigger functions, we could
>> try to "aggregate" the constraint-specific events somehow, but I think a
>> separate queue would be needed for the constraint-specific events.
>>
>> In general,
On Wed, Jul 24, 2019 at 8:30 PM Martijn van Oosterhout
wrote:
> I'll give it a shot a see how it looks.
Moved to September CF, "Waiting on Author".
--
Thomas Munro
https://enterprisedb.com
On Thu, Jul 4, 2019 at 8:25 PM Julien Rouhaud wrote:
> On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
> > On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > > So the patch compiles and works as intended. I don't have much to say
> > > about it, it all looks good to me, sin
On Thu, Jul 18, 2019 at 1:28 AM Nikita Glukhov wrote:
> 1. I fixed some bugs (fixed patch with additional test cases is attached):
Hi Nikita,
Thanks. I have set this to "Needs review", in the September 'fest.
--
Thomas Munro
https://enterprisedb.com
On Thu, Aug 1, 2019 at 5:38 PM Arne Roland wrote:
> Hello,
>
> I attached one example of a partitioned table with multi column partition
> key. I also attached the output.
> Disabling the hash_join is not really necessary, it just shows the more
> drastic result in the case of low work_mem.
>
> C
On Tue, Jul 30, 2019 at 9:39 AM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
>
> I am almost done writing the patch for pg_combinebackup and will post soon.
>
Attached patch which implements the pg_combinebackup utility used to combine
full basebackup with one or more incremental ba
On Wed, Jul 31, 2019 at 6:27 AM Karl O. Pinc wrote:
> On Tue, 30 Jul 2019 11:40:03 -0400
> Tom Lane wrote:
> [review]
> Thanks for the help. I will wait for a response to this
> before submitting another patch, just in case someone sees any
> ideas here to be followed up on.
Based on the above
On Thu, Aug 01, 2019 at 11:34:34AM +0200, Fabien COELHO wrote:
> However there is a contrary objective to have a unified interface,
> but there also exists a:
>
> extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
>
> called 3 times, always with base == 10. We have a simila
On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> I've moved this to the next CF, and set it to "Needs review" since a
> rebase was provided.
I may be missing something of course, but in this case we argued about
adding a couple of more fields. In consequence, the patch should be
wa
Hi,
Le jeu. 1 août 2019 à 13:51, Michael Paquier a écrit :
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
On Thu, Aug 1, 2019 at 11:51 PM Michael Paquier wrote:
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
> addi
Hello,
shouldn't we update associated commitfest entry
https://commitfest.postgresql.org/15/1318/
to give it a chance to be included in pg13 ?
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
Hi Vignesh,
On Thu, Aug 1, 2019 at 9:32 PM vignesh C wrote:
> In the undo system, we use full-transaction-id for transactions. For
> rollback of prepared transactions, we were planning to use
> FullTransactionId by combining TransactionId and epoch, but as
> suggested by multiple people in that
2019年8月1日(木) 19:24 Tomas Vondra :
>
> On Thu, Aug 01, 2019 at 06:28:08PM +0900, Kohei KaiGai wrote:
> >2019年8月1日(木) 16:19 Richard Guo :
> >>
> >> On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
> >>>
> >>> 2019年8月1日(木) 1:41 Tom Lane :
> >>> >
> >>> > Robert Haas writes:
> >>> > > Yeah, but I h
Hi,
Attached fixes some typos for "serialise" => "serialize" and "materialise"
=> "materialize".
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From 30d34d082120ac2c041a4ad45e9d6e31b0ea9c9d Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni
Date: Thu, 1 Aug 2019 0
Hi Ryan,
sorry for not be fast to replay
> I was suggesting a warning in the documentation so users aren't caught
> unaware about the performance characteristics. My first version was very
> rough, how about adding this in doc/src/sgml/ref/select.sgml?
>
> "Using PERCENT is best suited to return
On Thu, Aug 1, 2019 at 2:53 AM Fabien COELHO wrote:
> All in all, pgbench overheads are small compared to postgres processing
> times and representative of a reasonably optimized client application.
It's pretty easy to devise tests where pgbench is client-limited --
just try running it with threa
On Thu, Aug 1, 2019 at 5:36 PM Thomas Munro wrote:
>
> Hi Vignesh,
>
> On Thu, Aug 1, 2019 at 9:32 PM vignesh C wrote:
> > In the undo system, we use full-transaction-id for transactions. For
> > rollback of prepared transactions, we were planning to use
> > FullTransactionId by combining Transa
Shay Rojansky writes:
>> I'm not sure we're any closer to a meeting of the minds on whether
>> consulting zone[1970].tab is a good thing to do, but we got an actual
>> user complaint[1] about how "localtime" should not be a preferred
>> spelling. So I want to go ahead and insert the discussed ant
Richard Guo writes:
> For the third query, a rough investigation shows that, the qual 'sl =
> 5' and 'sc.sl = sg.sl' will form an equivalence class and generate two
> implied equalities: 'sc.sl = 5' and 'sg.sl = 5', which can be pushed
> down to the base rels. One consequence of the deduction is
Julien Rouhaud writes:
> Attached v4 that should address all comments.
Eyeing this a bit further ... doesn't scanPendingInsert also need
to honor so->forcedRecheck? Something along the lines of
- tbm_add_tuples(tbm, &pos.item, 1, recheck);
+ tbm_add_t
On Thu, 1 Aug 2019 at 11:30, Tomas Vondra wrote:
>
> I'll move it to the next CF. Aside from the issues pointed by Kyotaro-san
> in his review, I still haven't made my mind about whether to base the use
> statistics targets set for the attributes. That's what we're doing now,
> but I'm not sure it
extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
called 3 times, always with base == 10. We have a similar name but a totally
different interface, so basically it would have to be replaced
by something like the first interface.
My understanding on this one was to nuke
On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > Attached v4 that should address all comments.
>
> Eyeing this a bit further ... doesn't scanPendingInsert also need
> to honor so->forcedRecheck? Something along the lines of
>
> - tbm_add_tuples(
Thanks Peter. V6 is pretty uncontroversial by me — the new
conditional ladder broken cleanly into cases of (1) all
subnet, (2) network/subnet mix, and (3) all network is a
little more verbose, but all in all makes things easier to
reason about.
> Do you have any final input on the testing, Brandur
Tom,
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
>"localtime", but it'll at least prevent new initdb runs from picking
> that.
Thanks! At least over time the problem will hopefully diminish.
On Thu, Aug 1, 2019 at 8:34 AM Brandur Leach wrote:
> Thanks Peter. V6 is pretty uncontroversial by me — the new
> conditional ladder broken cleanly into cases of (1) all
> subnet, (2) network/subnet mix, and (3) all network is a
> little more verbose, but all in all makes things easier to
> reaso
On 26.07.2019 20:43, Liudmila Mantrova wrote:
I would like to suggest a couple of changes to docs and comments,
please see the attachment.
The "...or fetched on startup" part also seems wrong here, but it's
not a part of your patch, so I'm going to ask about it on psql-docs
separately.
Agre
On 31.07.2019 19:56, Heikki Linnakangas wrote:
On 09/07/2019 23:59, Konstantin Knizhnik wrote:
Fixed patch version of the path is attached.
Much of the patch and the discussion has been around the raw parsing,
and guessing which literals are actually parameters that have been
inlined into
Hi,
On 2019-08-01 20:08:15 +1200, Thomas Munro wrote:
> On Tue, Jul 30, 2019 at 5:58 PM Andres Freund wrote:
> > > +#include "c.h"
> > > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
> >
> > Hm, I'm not really sure that this does that much. Especially when the
> > call is via a func
Hi,
On 2019-08-01 10:08:01 -0400, Tom Lane wrote:
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
> "localtime", but it'll at least prevent new initdb runs from picking
> that.
> Avoid choosing "localt
On Thu, Aug 1, 2019 at 4:45 AM Thomas Munro wrote:
> On Tue, Jul 23, 2019 at 4:51 PM Tatsuro Yamada
> wrote:
> > Attached v4 patch file only includes this fix.
>
> I've moved this to the September CF, where it is in "Needs review" state.
/me reviews.
+ scanning_table
I think this should b
Hi,
On 2019-08-01 08:52:52 +0200, Fabien COELHO wrote:
> sh> time pgbench -r -T 30 -M prepared
> ...
> latency average = 2.425 ms
> tps = 412.394420 (including connections establishing)
> statement latencies in milliseconds:
> 0.001 \set aid random(1, 10 * :scale)
> 0.000 \
Hi,
On 2019-08-01 12:23:42 -0400, Robert Haas wrote:
> Barring objections, I plan to commit the whole series of patches here
> (latest rebase attached). They are not perfect and could likely be
> improved in various ways, but I think they are an improvement over
> what we have now, and it's not l
26.07.2019 21:26, Tom Lane wrote:
I took a quick look at this and I have a couple of gripes ---
* The naming and documentation of transform_const_function_to_result
seem pretty off-point to me. ISTM the real goal of that function is to
pull up constant values from RTE_FUNCTION RTEs. Replacing
On Thu, Aug 1, 2019 at 1:53 PM Andres Freund wrote:
> Could you wait until I either had a chance to look again, or until, say,
> Monday if I don't get around to it? I'll try to get to it earlier than
> that.
Sure, no problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
Andres Freund writes:
> When used and a symlink, could we resolve the symlink when determining
> the timezone? When loading a timezone in the backend, not during
> initdb. While that'd leave us with the instability, it'd at least would
> help clients etc understand what the setting actually means?
On Thu, Aug 1, 2019 at 2:46 AM Julien Rouhaud wrote:
> This patch is actually storing the queryid in PGPROC, not in
> PgBackendStatus, thus the need for an atomic. I used PGPROC because
> the value needs to be available in log_line_prefix() and spi.c, so
> pgstat.c / PgBackendStatus didn't seem l
Hi,
On 2019-08-01 13:59:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > When used and a symlink, could we resolve the symlink when determining
> > the timezone? When loading a timezone in the backend, not during
> > initdb. While that'd leave us with the instability, it'd at least would
> >
On 2019-08-01 14:20:46 -0400, Robert Haas wrote:
> However, I think that the fact that this patch adds 15 new calls to
> pg_atomic_write_u64(&MyProc->queryId, ...) is probably not a good
> sign. It seems like we ought to be able to centralize it better than
> that.
+1
Hi,
On 2019-08-01 08:45:45 +0200, Julien Rouhaud wrote:
> On Wed, Jul 31, 2019 at 11:59 PM Andres Freund wrote:
> > And if it were necessary, why wouldn't any of the other fields in
> > PgBackendStatus need it? There's plenty of other fields written to
> > without a lock, and several of those are
Hmm, I'm trying this out now and I don't see the index_rebuild_count
ever go up. I think it's because the indexes are built using parallel
index build ... or maybe it was the table AM changes that moved things
around, not sure. There's a period at the end when the CLUSTER command
keeps working, b
On 17/06/2019 15:53, Paul Guo wrote:
I noticed that to do batch insert, we might need additional memory copy
sometimes comparing with "single insert"
(that should be the reason that we previously saw a bit regressions) so a
good solution seems to fall back
to "single insert" if the tuple length i
>
> It seems this topic is ongoing so I've moved it to the September CF,
> but it's in "Waiting on Author" because we don't have a concrete patch
> that applies (or agreement on what it should do?) right now.
>
All recent work has been investigating the need(s) we're trying to address.
This is as
Julien Rouhaud writes:
> On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
>> Eyeing this a bit further ... doesn't scanPendingInsert also need
>> to honor so->forcedRecheck? Something along the lines of
> I think so.
Yeah, it does --- the updated pg_trgm test attached fails if it doesn't.
Also,
Andres Freund writes:
> Fair enough. I'm mildly worried that people will just carry their
> timezone setting from one version's postgresql.conf to the next as they
> upgrade.
Maybe. I don't believe pg_upgrade copies over the old postgresql.conf,
and I doubt we should consider it good practice in
On Thu, Aug 1, 2019 at 9:59 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
> >> Eyeing this a bit further ... doesn't scanPendingInsert also need
> >> to honor so->forcedRecheck? Something along the lines of
>
> > I think so.
>
> Yeah, it does -
Alexander Korotkov writes:
> On Thu, Aug 1, 2019 at 9:59 PM Tom Lane wrote:
>> While I've not attempted to fix that here, I wonder whether we shouldn't
>> fix it by just forcing forcedRecheck to true in any case where we discard
>> an ALL qualifier.
> +1 for setting forcedRecheck in any case we
>
>
> > The people who expressed opinions on nuking triggers from orbit (it's
> the only way to be sure) have yet to offer up any guidance on how to
> proceed from here, and I suspect it's because they're all very busy getting
> things ready for v12. I definitely have an interest in working on this
I pushed a commit that required a new pg_proc entry today. Had I not
been involved with the work that became commit a6417078, I would
definitely not have used an OID from the range reserved for devel
system catalogs (8000 - 8999). As I understand it, this is now
standard practice.
Perhaps unsurpri
On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
>
> On 2019-08-01 08:45:45 +0200, Julien Rouhaud wrote:
> > On Wed, Jul 31, 2019 at 11:59 PM Andres Freund wrote:
> > > And if it were necessary, why wouldn't any of the other fields in
> > > PgBackendStatus need it? There's plenty of other fiel
"Tom Lane" wrote:
> Uh ... why? The pushed-down restrictions should result in pruning
> away any prunable partitions at the scan level, leaving nothing for
> the partitionwise join code to do.
It seems reasonable to me that the join condition can no longer be verified,
since 'sc.sl = sg.sl' is
Hello Richard,
thanks for your quick reply.
> We need to fix this.
Do you have a better idea than just keeping the old quals - possibly just the
ones that get eliminated - in a separate data structure? Is the push down of
quals the only case of elimination of quals, only counting the ones w
On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
>
> On 2019-08-01 14:20:46 -0400, Robert Haas wrote:
> > However, I think that the fact that this patch adds 15 new calls to
> > pg_atomic_write_u64(&MyProc->queryId, ...) is probably not a good
> > sign. It seems like we ought to be able to cen
1 - 100 of 137 matches
Mail list logo
