On Thu, Aug 20, 2020 at 05:09:05PM +0900, Michael Paquier wrote:
> That could be helpful. Wouldn't it be better to use "end-of-recovery
> checkpoint" instead? That's the common wording in the code comments.
>
> I don't see the point of patch 0002. In the same paragraph, we
> already know that t
On Mon, Aug 31, 2020 at 10:36:13AM +0530, Rahila wrote:
> Now, the relreplident is being set in the transaction previous to
> the one marking index as invalid for concurrent drop. Won't
> it cause issues with relreplident cleared but index not dropped,
> if drop index concurrently fails in the smal
On Sat, Aug 29, 2020 at 3:33 AM Robert Haas wrote:
> I think David's points elsewhere on the thread about ProjectSet and
> Materialize nodes are interesting.
Indeed, I'm now finding it very difficult to look past the similarity with:
postgres=# explain select count(*) from t t1 cross join t t2;
Hi,
I updated the wiki page.
https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
On Fri, 21 Aug 2020 21:40:50 +0900 (JST)
Tatsuo Ishii wrote:
> From: Yugo NAGATA
> Subject: Re: Implementing Incremental View Maintenance
> Date: Fri, 21 Aug 2020 17:23:20 +0900
> Message-ID: <2020082117
> On Aug 31, 2020, at 11:43 AM, Thomas Munro wrote:
>
> On Mon, Aug 31, 2020 at 2:40 PM Li Japin wrote:
>> Could you give the more details about the test instructions?
>
> Hi Japin,
>
> Sure. Because I wasn't trying to get reliable TPS number or anything,
> I just used a simple short read-o
On Sun, Aug 30, 2020 at 2:43 PM Dilip Kumar wrote:
>
> On Sat, Aug 29, 2020 at 5:18 PM Amit Kapila wrote:
> >
>
> > One more comment for which I haven't done anything yet.
> > +static void
> > +set_schema_sent_in_streamed_txn(RelationSyncEntry *entry, TransactionId
> > xid)
> > +{
> > + MemoryCo
On Thu, Aug 27, 2020 at 07:53:23PM -0400, Alvaro Herrera wrote:
> +1 for the general idea, and +1 for \dX being the syntax to use
>
> IMO the per-type columns should show both the type being enabled as
> well as it being built.
>
> (How many more stat types do we expect -- Tomas? I wonder if hav
On Thu, 13 Aug 2020 at 17:18, Dilip Kumar wrote:
> I have rebased the patch on the latest head and currently, broken into 3
> parts.
>
> v1-0001: As suggested by Robert, it provides the syntax support for
> setting the compression method for a column while creating a table and
> adding columns.
ne 30. 8. 2020 v 23:59 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > This is nice example of usage of anycompatible type (that is consistent
> > with other things in Postgres), but standard says something else.
> > It can be easily solved with https://commitfest.postgresql.org/28/2081/
The stats target can be set since commit d06215d03, but wasn't shown by psql.
ALTER STATISISTICS .. SET STATISTICS n.
Normal (1-D) stats targets are shown in \d+ table.
Stats objects are shown in \d (no plus).
Arguably, this should be shown only in "verbose" mode (\d+).
>From 60a4033a04fbaafbb01c
At Mon, 31 Aug 2020 12:51:20 +1200, Thomas Munro wrote
in
> On Tue, Aug 18, 2020 at 2:13 PM Li Japin wrote:
> > On Aug 18, 2020, at 9:19 AM, Kyotaro Horiguchi
> > wrote:
> > The same already happens for idle_in_transaction_session_timeout and
> > we can use "ALTER ROLE/DATABASE SET" to dislab
On Mon, Aug 31, 2020 at 2:40 PM Li Japin wrote:
> Could you give the more details about the test instructions?
Hi Japin,
Sure. Because I wasn't trying to get reliable TPS number or anything,
I just used a simple short read-only test with one connection, like
this:
pgbench -i -s10 postgres
pgbe
On Sun, Aug 30, 2020 at 02:03:32PM +0100, David CARLIER wrote:
> Thanks.
During the addition of explicit_bzero(), there was an agreement to use
memset_s(), as it is blessed by the standard:
https://www.postgresql.org/message-id/20190717211931.GA906@alvherre.pgsql
So what would be the advantage of
On Aug 31, 2020, at 8:51 AM, Thomas Munro
mailto:thomas.mu...@gmail.com>> wrote:
The main problem I have with it is the high frequency setitimer()
calls. If you enable both statement_timeout and idle_session_timeout,
then we get up to huge number of system calls, like the following
strace -c o
On Sun, 30 Aug 2020 at 11:26, Tom Lane wrote:
>
> I wrote:
> > Therefore, I'm considering the idea of ripping out all executor support
> > for AlternativeSubPlan and instead having the planner replace an
> > AlternativeSubPlan with the desired specific SubPlan somewhere late in
> > planning, possi
On 2020/08/31 1:59, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
I wonder how to report that. Knowing that psql \-commands are not meant
for anything other than human consumption, maybe we can use a format()
string that says "built: %d b
On Tue, Aug 18, 2020 at 2:13 PM Li Japin wrote:
> On Aug 18, 2020, at 9:19 AM, Kyotaro Horiguchi
> wrote:
> The same already happens for idle_in_transaction_session_timeout and
> we can use "ALTER ROLE/DATABASE SET" to dislable or loosen them, it's
> a bit cumbersome, though. I don't think we sh
On Sun, Aug 30, 2020 at 7:26 AM Tom Lane wrote:
> I wrote:
> > Back in bd3daddaf232d95b0c9ba6f99b0170a0147dd8af, which introduced
> > AlternativeSubPlans, I wrote:
> > There is a lot more that could be done based on this infrastructure: in
> > particular it's interesting to consider switching
Hi Alvaro,
IMO the per-type columns should show both the type being enabled as
well as it being built.
Hmm. I'm not sure how to get the status (enabled or disabled) of
extended stats. :(
Could you explain it more?
pg_statistic_ext_data.stxdndistinct is not null if the stats have been
built.
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> > > * Magnus Hagander (mag...@hagander.net) wrote:
> > > > Without having actually looked at the code, definite +1 for this
> > > > f
Pavel Stehule writes:
> This is nice example of usage of anycompatible type (that is consistent
> with other things in Postgres), but standard says something else.
> It can be easily solved with https://commitfest.postgresql.org/28/2081/ -
> but Tom doesn't like this patch.
> I am more inclined to
Mark Dilger writes:
> [ v3-0001-Adding-deprecation-notices.patch ]
Pushed with some fiddling.
We previously found that adding id tags to constructs in the
function lists didn't work in PDF output [1]. Your patch did build
a PDF without warnings for me, which is odd --- apparently we changed
so
ne 30. 8. 2020 v 18:23 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I'll mark this patch as ready for commit
>
> Pushed, thanks for looking.
>
Thank you
Pavel
>
> regards, tom lane
>
Tomas Vondra writes:
> On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
>> I wonder how to report that. Knowing that psql \-commands are not meant
>> for anything other than human consumption, maybe we can use a format()
>> string that says "built: %d bytes" when \dX+ is used (for
> On Aug 28, 2020, at 8:56 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> So, in this version, there are six copies of the deprecation notice
>> John wrote, rather than just one. Maybe we need more than one, but I
>> doubt we need six. I don't think the CREATE OPERATOR documentation
>> needs t
On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
On 2020-Aug-30, Tomas Vondra wrote:
On Sat, Aug 29, 2020 at 06:43:47PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-29, Tomas Vondra wrote:
> > Also, it might be useful to show the size of the statistics built, just
> > like we sh
On 2020-Aug-30, Tomas Vondra wrote:
> On Sat, Aug 29, 2020 at 06:43:47PM -0400, Alvaro Herrera wrote:
> > On 2020-Aug-29, Tomas Vondra wrote:
> > > Also, it might be useful to show the size of the statistics built, just
> > > like we show for \d+ etc.
> >
> > \dX+ I suppose?
>
> Right. I've o
Pavel Stehule writes:
> I'll mark this patch as ready for commit
Pushed, thanks for looking.
regards, tom lane
On Sun, Aug 30, 2020 at 02:26:20AM +0200, Tomas Vondra wrote:
On Fri, Aug 28, 2020 at 06:32:38PM -0700, Jeff Davis wrote:
On Thu, 2020-08-27 at 17:28 -0700, Peter Geoghegan wrote:
We have a Postgres 13 open item for Disk-based hash aggregate, which
is the only non-trivial open item. There is a
Thomas Munro writes:
> A couple of recent cases where an error "libpq is incorrectly linked
> to backend functions" broke the dblink test:
lorikeet seems just plain unstable these days :-(. Don't know why.
> ... curiously the message also appeared a
> couple of times on two Unixen. Perhaps we
Thanks.
Regards.
0001-explicit_bzero.c-uses-explicit_memset-for-NetBSD.patch
Description: Binary data
> 27 авг. 2020 г., в 21:03, Pavel Borisov написал(а):
>
> see v8
For me is the only concerning point is putting nullmask and varatt bits into
tuple->nextOffset.
But, probably, we can go with this.
But let's change macro a bit. When I see
SGLT_SET_OFFSET(leafTuple->nextOffset, InvalidOffsetN
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Aug 27, 2020 at 04:28:54PM -0400, Stephen Frost wrote:
> >* Robert Haas (robertmh...@gmail.com) wrote:
> >>On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost wrote:
> >>> > Hm? At least earlier versions didn't do prefetching for
> 23 авг. 2020 г., в 14:39, Andrey M. Borodin написал(а):
>
> Thanks for reviewing and benchmarking, Pavel!
Pavel sent me few typos offlist. PFA v12 fixing these typos.
Thanks!
Best regards, Andrey Borodin.
v12-0001-Add-sort-support-for-point-gist_point_sortsuppor.patch
Description: Binary
Hi all,
In the current lazy vacuum implementation, some index AMs such as
btree indexes call lazy_tid_reaped() for each index tuples during
ambulkdelete to check if the index tuple points to the (collected)
garbage tuple. In that function, we simply call bsearch(3) but we
should be able to know th
On Thu, Aug 27, 2020 at 11:02 AM Peter Smith wrote:
>
> Hello.
>
> FYI - that patch has conflicts when applied.
>
Thanks for letting me know. Attached new patch which is rebased on top of head.
Regards,
VIgnesh
EnterpriseDB: http://www.enterprisedb.com
From a343fe1f8fdf4293d2ef6841e243390b99f29e
On Thu, Aug 27, 2020 at 11:28:35AM +0900, Michael Paquier wrote:
> Attached is a patch for 1) and 2) grouped together, to ease review for
> now. I think that we had better fix 1) separately though, so I am
> going to start a new thread about that with a separate patch as the
> current thread is mi
37 matches
Mail list logo
