Thanks for reviewing again
On Sun, Feb 02, 2020 at 10:45:12AM +0900, Masahiko Sawada wrote:
> Thank you for updating the patch. Here is some review comments:
>
> 1.
> +typedef struct
> +{
> + char*relnamespace;
> + char*relname;
> + char*indname; /* If vacuuming
On Fri, 31 Jan 2020 at 02:29, Fujii Masao wrote:
>
>
>
> On 2020/01/30 12:58, Kyotaro Horiguchi wrote:
> > At Wed, 29 Jan 2020 23:16:08 +0900, Fujii Masao
> > wrote in
> >> Hi,
> >>
> >> pg_basebackup reports the backup progress if --progress option is
> >> specified,
> >> and we can monitor it
On Wed, 29 Jan 2020 at 17:56, Amit Langote wrote:
>
> On Wed, Jan 29, 2020 at 11:29 AM yuzuko wrote:
> > > Besides the complexity of
> > > getting that infrastructure in place, an important question is whether
> > > the current system of applying threshold and scale factor to
> > >
On Tue, 28 Jan 2020 at 07:50, Justin Pryzby wrote:
>
> On Mon, Jan 27, 2020 at 03:59:58PM +0900, Masahiko Sawada wrote:
> > On Mon, 27 Jan 2020 at 14:38, Justin Pryzby wrote:
> > > On Sun, Jan 26, 2020 at 12:29:38PM -0800, Andres Freund wrote:
> > > > > CONTEXT: while vacuuming relation
Hi,
I've started a new separate thread from the previous long thread[1]
for internal key management system to PostgreSQL. As I mentioned in
the previous mail[2], we've decided to step back and focus on only
internal key management system for PG13. The internal key management
system introduces the
I wrote:
> Either way, though, the WW weeks don't line up with the D weeks,
> and we're not likely to make them do so.
> So I think an acceptable version of this feature has to involve
> defining at least one new format code and maybe as many as three,
> to produce year, week and day values that
Hamid Akhtar writes:
> I've reviewed and verified this patch and IMHO, this is ready to be committed.
I took a look at this and I don't think it's really going in the right
direction. ISTM the clear intent of this code was to attach the "Subplans
Removed" item as a field of the parent
so 1. 2. 2020 v 14:39 odesílatel 曾文旌(义从)
napsal:
>
>
> 2020年1月30日 下午10:21，Pavel Stehule 写道：
>
>
>
> č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
>> >>> +
> 2020年1月27日 下午5:38，Konstantin Knizhnik 写道：
>
>
>
> On 25.01.2020 18:15, 曾文旌(义从) wrote:
>> I wonder why do we need some special check for GTT here.
>>> From my point of view cleanup at startup of local storage of temp tables
>>> should be performed in the same way for local and global temp
On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada
wrote:
> On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkuni wrote:
> > That
> > would allow the internal usage to have a fixed output length of
> > LEN(IV) + LEN(HMAC) + LEN(DATA) = 16 + 32 + 64 = 112 bytes.
>
> Probably you meant LEN(DATA) is 32? DATA
Michael Paquier writes:
> On Fri, Jan 31, 2020 at 05:13:53PM -0500, Tom Lane wrote:
>> Also, %zd is the wrong format code for int64. Recommended practice
>> these days is to use "%lld" with an explicit cast of the printf argument
>> to long long (just to be sure). That doesn't work safely
On Sat, Feb 01, 2020 at 08:51:04AM +0100, Pierre Ducroquet wrote:
Hello
At my current job, we have a lot of multi-tenant databases, thus with tables
containing a tenant_id column. Such a column introduces a severe bias in
statistics estimation since any other FK in the next columns is very
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
regards
--
Tomas Vondra
This patch was broken and waiting for author since early December, so
I've marked it as returned with feedback. Feel free to resubmit an
updated version to a future commitfest.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA,
Hi,
this patch was marked as waiting on author since the beginning of the
CF, most likely because it no longer applies (not sure). As there has
been very little activity since then, I've marked it as returned with
feedback. Feel free to re-submit an updated patch for 2020-03.
This definitely
Hi,
this patch was waiting on author without any update/response since early
December, so I've marked it as returned with feedback. Feel free to
re-submit an updated version to a future CF.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7
Hi, the patch was in WoA since December, waiting for a rebase. I've
marked it as returned with feedback. Feel free to re-submit an updated
version into the next CF.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
so 1. 2. 2020 v 12:34 odesílatel Tomas Vondra
napsal:
> This patch was in WoA, but that was wrong I think - we got a patch on
> January 15, followed by a benchmark by Pavel Stehule, so I think it
> should still be in "needs review". So I've updated it and moved it to
> the next CF.
>
currently
This patch was in WoA, but that was wrong I think - we got a patch on
January 15, followed by a benchmark by Pavel Stehule, so I think it
should still be in "needs review". So I've updated it and moved it to
the next CF.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
On Fri, Nov 29, 2019 at 09:39:09AM +0100, Julien Rouhaud wrote:
On Fri, Nov 29, 2019 at 7:21 AM Michael Paquier wrote:
On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote:
> On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote:
>> I'd really like to have the queryid
I've marked this patch as returned with feedback. It's been sitting in
the CF for a long time without any update (and does not apply anymore).
That does not mean we don't want the feature (it seems useful) so feel
free to resubmit an updated patch.
regards
--
Tomas Vondra
I've marked this patch as returned with feedback. It's been sitting in
the CF without any response from the author since September, and it's
not quite clear we actually want/need this feature. If needed, the patch
can be resubmitted for 2020-03.
regards
--
Tomas Vondra
Hi,
I've moved this patch to the next CF - it's still in WoA state, but it's
supposedly a bugfix so I've decided not to return it with feedback.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello Alvaro,
I read the whole thread, I still don't know what this patch is supposed to
do. I know what the words in the subject line mean, but I don't know how
this helps a pgbench user run better benchmarks. I feel this is also the
sentiment expressed by others earlier in the thread. You
> On 24 Jan 2020, at 08:27, Peter Eisentraut
> wrote:
>
> I definitely want to make it work in a way that does not require writing C
> code. My idea was to create a new type, perhaps called "descriptor", that
> represents essentially a tuple descriptor. (It could be exactly a TupleDesc,
>
On Fri, Jan 31, 2020 at 05:13:53PM -0500, Tom Lane wrote:
> +1 for widening these counters, but since they're global variables, -0.2
> or so for back-patching. I don't know of any reason that an extension
> would be touching these, but I feel like the problem isn't severe enough
> to justify
On Thu, Jan 30, 2020 at 04:00:40PM +0900, Michael Paquier wrote:
> Anyway, your patch looks like a good idea to me, so let's see if
> others have opinions or objections about it.
Seeing nothing, committed v2.
--
Michael
signature.asc
Description: PGP signature
> On 28 Jan 2020, at 09:56, Thomas Munro wrote:
>
> ([…] I have no
> idea what GUI interaction causes that, but most Apple Mail attachments
> seem to be fine.)
I gathered from the other thread that posting plain text seems to attach the
patches in a way that’s more acceptable. Seems to work,
Hello Peter,
This patch was marked as RFC on 2019-03-30, but since then there have
been a couple more issues pointed out in a review by Thomas Munro, and
it went through 2019-09 and 2019-11 without any attention. Is the RFC
status still appropriate?
Thomas review was about
Hello
At my current job, we have a lot of multi-tenant databases, thus with tables
containing a tenant_id column. Such a column introduces a severe bias in
statistics estimation since any other FK in the next columns is very likely to
have a functional dependency on the tenant id. We found
30 matches
Mail list logo
