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
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
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
> 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
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
> 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
Thanks.
Regards.
0001-explicit_bzero.c-uses-explicit_memset-for-NetBSD.patch
Description: Binary data
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
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
Pavel Stehule writes:
> I'll mark this patch as ready for commit
Pushed, thanks for looking.
regards, tom lane
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
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 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
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
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
>
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
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
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
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.
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
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 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 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 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, 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 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
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
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
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/
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.
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 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
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 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;
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 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
37 matches
Mail list logo
