Re: PostgresSQL 13.0 Beta 1 on Phoronix

On Sun, May 24, 2020 at 02:50:08PM -0300, Ranier Vilela wrote: > Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan escreveu: >> It looks like they're only running pgbench for 60 second runs in all >> configurations -- notice that "-T 60" is passed to pgbench. I'm not >> entirely sure that that

Re: WAL reader APIs and WAL segment open/close callbacks

At Mon, 25 May 2020 14:19:34 +0900, Michael Paquier wrote in > On Mon, May 25, 2020 at 11:17:06AM +0900, Kyotaro Horiguchi wrote: > > That depends on where we draw responsibility border, or who is > > responsible to the value of ws_file. I think that this API change was > > assuming the callbac

Re: pg13 docs: minor fix for "System views" list

On Mon, May 25, 2020 at 03:12:57PM +0900, Fujii Masao wrote: > Thanks! LGTM. Will commit this. Oops :) -- Michael signature.asc Description: PGP signature

Re: pg13 docs: minor fix for "System views" list

On Mon, May 25, 2020 at 11:03:01AM +0900, Ian Barwick wrote: > "pg_shmem_allocations" is not quite in alphabetical order and > needs to be swapped with the preceding entry, per attached patch. Thanks, fixed! -- Michael signature.asc Description: PGP signature

Re: pg13 docs: minor fix for "System views" list

On 2020/05/25 11:03, Ian Barwick wrote: Hi In this list:   https://www.postgresql.org/docs/devel/views-overview.html "pg_shmem_allocations" is not quite in alphabetical order and needs to be swapped with the preceding entry, per attached patch. Thanks! LGTM. Will commit this. Regards,

Re: WAL reader APIs and WAL segment open/close callbacks

On Mon, May 25, 2020 at 11:17:06AM +0900, Kyotaro Horiguchi wrote: > That depends on where we draw responsibility border, or who is > responsible to the value of ws_file. I think that this API change was > assuming the callbacks having full-knowledge of the xlogreader struct > and are responsible

Re: WAL reader APIs and WAL segment open/close callbacks

At Mon, 25 May 2020 07:44:09 +0900, Michael Paquier wrote in > Hi all, > > I have been playing with the new APIs of xlogreader.h, and while > merging some of my stuff with 13, I found the handling around > ->seg.ws_file overcomplicated and confusing as it is necessary for a > plugin to manipula

Re: Trouble with hashagg spill I/O pattern and costing

On Thu, May 21, 2020 at 11:41:22PM +0200, Tomas Vondra wrote: On Thu, May 21, 2020 at 02:16:37PM -0700, Jeff Davis wrote: On Thu, 2020-05-21 at 21:13 +0200, Tomas Vondra wrote: 2) We could make it self-tuning, by increasing the number of blocks we pre-allocate. So every time we exhaust the rang

pg13 docs: minor fix for "System views" list

Hi In this list: https://www.postgresql.org/docs/devel/views-overview.html "pg_shmem_allocations" is not quite in alphabetical order and needs to be swapped with the preceding entry, per attached patch. Regards Ian Barwick -- Ian Barwick https://www.2ndQuadrant.com/ Pos

Re: Add explanations which are influenced by track_io_timing

On Fri, May 22, 2020 at 11:37 PM Fujii Masao wrote: > > > On 2020/05/15 9:50, Atsushi Torikoshi wrote: > > Thanks for reviewing! > > > > On Wed, May 13, 2020 at 11:27 PM Fujii Masao < > masao.fu...@oss.nttdata.com > wrote: > > > > What about the attached pa

Re: Is it useful to record whether plans are generic or custom?

Thanks for writing a patch! On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi wrote: > At Thu, 21 May 2020 12:18:16 +0900, Fujii Masao < > masao.fu...@oss.nttdata.com> wrote in > > I like the idea exposing more CachedPlanSource fields in > > pg_prepared_statements. I agree it's useful, e.g., for

Re: Failure to create GiST on ltree column

On Sun, May 24, 2020 at 09:30:15PM +0300, Victor Yegorov wrote: > Greetings. > > I am getting random failures in `CREATE INDEX USING gist` over ltree column > while performing pg_restore. > I get either > ERROR: stack depth limit exceeded > or > ERROR: failed to add item to index page >

WAL reader APIs and WAL segment open/close callbacks

Hi all, I have been playing with the new APIs of xlogreader.h, and while merging some of my stuff with 13, I found the handling around ->seg.ws_file overcomplicated and confusing as it is necessary for a plugin to manipulate directly the fd of an opened segment in the WAL segment open/close callba

Missing links between system catalog documentation pages

Hi hackers, While browsing the system catalog docs earlier I noticed that a lot of them mention other catalogs or views in the introductory paragrah without hyperlinking them. Now, most of these are linked in the "references" column in the table, but some, like pg_proc's mention of pg_aggregate h

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Sun, 24 May 2020 at 04:14, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, May 22, 2020 at 08:40:17AM +1200, David Rowley wrote: > > I imagine we'll set some required UniqueKeys during > > standard_qp_callback() > > In standard_qp_callback, because pathkeys are computed at this point

Failure to create GiST on ltree column

Greetings. I am getting random failures in `CREATE INDEX USING gist` over ltree column while performing pg_restore. I get either ERROR: stack depth limit exceeded or ERROR: failed to add item to index page Thing is — if I retry index creation manually, I get it successfully built in ~50

Re: Parallel Seq Scan vs kernel read ahead

On Sat, 23 May 2020 at 06:31, Robert Haas wrote: > > On Thu, May 21, 2020 at 6:28 PM Thomas Munro wrote: > > Right, I think it's safe. I think you were probably right that > > ramp-up isn't actually useful though, it's only the end of the scan > > that requires special treatment so we don't get

Re: PostgresSQL 13.0 Beta 1 on Phoronix

Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan escreveu: > On Sun, May 24, 2020 at 2:52 AM Ranier Vilela wrote: > > There was news in Phoronix about the Beta 1 Release of Postgres (1). > > Unfortunately for Postgres advocacy it does not bring good news, > > it is showing regressions in th

Re: PostgresSQL 13.0 Beta 1 on Phoronix

On Sun, May 24, 2020 at 2:52 AM Ranier Vilela wrote: > There was news in Phoronix about the Beta 1 Release of Postgres (1). > Unfortunately for Postgres advocacy it does not bring good news, > it is showing regressions in the benchmarks compared to version 12. > Without going into the technical me

Re: Default gucs for EXPLAIN

Why not allowing the following:  EXPLAIN [ ANALYZE ] [ VERBOSE ] [ ( option [, ...] ) ] statement That has nothing to do with this patch. Sure, it was just in passing, I was surprised by this restriction. -- Fabien.

PostgresSQL 13.0 Beta 1 on Phoronix

Hi, There was news in Phoronix about the Beta 1 Release of Postgres (1). Unfortunately for Postgres advocacy it does not bring good news, it is showing regressions in the benchmarks compared to version 12. Without going into the technical merits of how the test was done, they have no way of knowing

Re: Default gucs for EXPLAIN

On 5/24/20 9:31 AM, Fabien COELHO wrote: > While testing the issue, I'm surprised at the syntax: > >  EXPLAIN [ ( option [, ...] ) ] statement >  EXPLAIN [ ANALYZE ] [ VERBOSE ] statement > > Why not allowing the following: > >  EXPLAIN [ ANALYZE ] [ VERBOSE ] [ ( option [, ...] ) ] statement T

Re: Default gucs for EXPLAIN

The safe option seems not allowing to change ANALYZE option default. EXPLAIN [ ANALYZE ] [ VERBOSE ] statement Some more thoughts: An argument for keeping it that way is that there is already a special syntax to enable ANALYSE explicitely, which as far as I am concerned I only ever atte

Re: Default gucs for EXPLAIN

Bonjour Vik, Do we really want default_explain_analyze ? It sounds like bad news that EXPLAIN DELETE might or might not remove rows depending on the state of a variable. I have had sessions where not using ANALYZE was the exception, not the rule. I would much prefer to type EXPLAIN (ANALYZE