Re: Hybrid Hash/Nested Loop joins and caching results from subplans

2020-08-30 Thread Thomas Munro
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;

Re: Terminate the idle sessions

2020-08-30 Thread Li Japin
> 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

Re: Implementing Incremental View Maintenance

2020-08-30 Thread Yugo NAGATA
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:

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

2020-08-30 Thread Amit Kapila
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) > > +{ > > +

Re: list of extended statistics on psql

2020-08-30 Thread Justin Pryzby
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

Re: Re: [HACKERS] Custom compression methods

2020-08-30 Thread Amit Khandekar
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.

Re: Compatible defaults for LEAD/LAG

2020-08-30 Thread Pavel Stehule
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

v13: show extended stats target in \d

2020-08-30 Thread Justin Pryzby
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

Re: Terminate the idle sessions

2020-08-30 Thread Kyotaro Horiguchi
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

Re: Terminate the idle sessions

2020-08-30 Thread Thomas Munro
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

Re: [PATCH v1] explicit_bzero.c: using explicit_memset on NetBSD

2020-08-30 Thread Michael Paquier
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

Re: Terminate the idle sessions

2020-08-30 Thread Li Japin
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

Re: Get rid of runtime handling of AlternativeSubPlan?

2020-08-30 Thread David Rowley
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,

Re: list of extended statistics on psql

2020-08-30 Thread Tatsuro Yamada
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

Re: Terminate the idle sessions

2020-08-30 Thread Thomas Munro
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

Re: Get rid of runtime handling of AlternativeSubPlan?

2020-08-30 Thread Andy Fan
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

Re: list of extended statistics on psql

2020-08-30 Thread Tatsuro Yamada
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.

Re: New default role- 'pg_read_all_data'

2020-08-30 Thread Stephen Frost
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 > > > >

Re: Compatible defaults for LEAD/LAG

2020-08-30 Thread Tom Lane
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

Re: Deprecating postfix and factorial operators in PostgreSQL 13

2020-08-30 Thread 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

Re: Row estimates for empty tables

2020-08-30 Thread Pavel Stehule
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 >

Re: list of extended statistics on psql

2020-08-30 Thread 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

Re: Deprecating postfix and factorial operators in PostgreSQL 13

2020-08-30 Thread Mark Dilger
> 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

Re: list of extended statistics on psql

2020-08-30 Thread Tomas Vondra
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

Re: list of extended statistics on psql

2020-08-30 Thread Alvaro Herrera
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

Re: Row estimates for empty tables

2020-08-30 Thread Tom Lane
Pavel Stehule writes: > I'll mark this patch as ready for commit Pushed, thanks for looking. regards, tom lane

Re: Disk-based hash aggregate's cost model

2020-08-30 Thread Tomas Vondra
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

Re: Rare link canary failure in dblink test

2020-08-30 Thread Tom Lane
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

[PATCH v1] explicit_bzero.c: using explicit_memset on NetBSD

2020-08-30 Thread David CARLIER
Thanks. Regards. 0001-explicit_bzero.c-uses-explicit_memset-for-NetBSD.patch Description: Binary data

Re: [PATCH] Covering SPGiST index

2020-08-30 Thread Andrey M. Borodin
> 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,

Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)

2020-08-30 Thread Stephen Frost
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

Re: Yet another fast GiST build (typo)

2020-08-30 Thread Andrey M. Borodin
> 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

Boundary value check in lazy_tid_reaped()

2020-08-30 Thread Masahiko Sawada
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

Re: Improvements in Copy From

2020-08-30 Thread vignesh C
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

Re: More tests with USING INDEX replident and dropped indexes

2020-08-30 Thread Michael Paquier
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