Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Wed, 7 Dec 2022 at 13:01, Alvaro Herrera wrote: > On 2022-Dec-06, Andres Freund wrote: > > > Hi, > > > > On 2022-11-25 02:45:01 +0500, Hamid Akhtar wrote: > > > Rebasing the patch to the tip of the master branch. > > > > This doesn't pass t

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Mon, 21 Nov 2022 at 17:34, Naeem Akhter wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation:not tested > >

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Wed, 12 Oct 2022 at 10:51, Michael Paquier wrote: > On Mon, Sep 12, 2022 at 03:18:59PM -0400, Tom Lane wrote: > > I spun up a 32-bit VM, since that had been on my to-do list anyway, > > and it looks like I was right: > > This feedback has not been addressed and the thread is idle four >

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Tue, 26 Jul 2022 at 21:35, Simon Riggs wrote: > On Fri, 15 Jul 2022 at 12:29, Aleksander Alekseev > wrote: > > Personally I didn't expect that > > merging patches in this thread would take that long. They are in > > "Ready for Committer" state for a long time now and there are no known > >

Re: add checkpoint stats of snapshot and mapping files of pg_logical dir

test case "33/238 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade with an "exit status 2" error. The details are available on the cfbot.cputue.org. https://cirrus-ci.com/task/5709014662119424?logs=check_world#L267 -- Hamid Akhtar, Percona LLC, www.percona.com

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Tue, 6 Sept 2022 at 11:25, Ibrar Ahmed wrote: > > > On Mon, Aug 1, 2022 at 11:29 PM Naeem Akhter > wrote: > >> The following review has been posted through the commitfest application: >> make installcheck-world: tested, passed >> Implements feature: tested, passed >> Spec compliant:

Re: CFM Manager

On Tue, 23 Aug 2022 at 1:26 AM, Ibrar Ahmed wrote: > > > On Mon, Aug 22, 2022 at 9:47 PM Jacob Champion > wrote: > >> On Mon, Aug 22, 2022 at 9:40 AM Tom Lane wrote: >> > You attribute more organization to this than actually exists ;-) >> >> Ha, fair enough! >> >> > If Ibrar wants the job I

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Sun, 31 Jul 2022 at 18:00, Hamid Akhtar wrote: > > > On Thu, 28 Jul 2022 at 00:36, Tom Lane wrote: > >> Hamid Akhtar writes: >> > That attached patch is based on the master branch. It makes the >> following >> > changes to the

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Thu, 28 Jul 2022 at 00:36, Tom Lane wrote: > Hamid Akhtar writes: > > That attached patch is based on the master branch. It makes the following > > changes to the pageinspect contrib module: > > - Updates bt_page_stats_internal function to accept 3 argumen

Re: explain analyze rows=%.0f

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested The previous review was incorrectly posted. Updating the pat.ch

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Fri, 1 Jul 2022 at 13:01, Drouvot, Bertrand wrote: > Hi, > On 6/30/22 10:24 AM, Hamid Akhtar wrote: > > On Mon, 27 Jun 2022 at 15:52, Bharath Rupireddy < > bharath.rupireddyforpostg...@gmail.com> wrote: > >> On Mon, Jun 27, 2022 at 1:40 PM Drouvot, Be

Re: explain analyze rows=%.0f

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: not tested Documentation:not tested LGTM

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Thu, 30 Jun 2022 at 14:27, Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Thu, Jun 30, 2022 at 1:54 PM Hamid Akhtar > wrote: > > > >> Do we have any > >> difference in the execution times for the above query vs the new >

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Mon, 27 Jun 2022 at 15:52, Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Mon, Jun 27, 2022 at 1:40 PM Drouvot, Bertrand > wrote: > > > > Hi, > > > > On 6/27/22 9:31 AM, Hamid Akhtar wrote: > > > > > > Hello Hack

Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

_stats('test2_col1_idx', 1, -1); DROP TABLE test2; Regards. -- Hamid Akhtar, Percona LLC, URL : www.percona.com CELL：+923335449950 SKYPE: engineeredvirus diff --git a/contrib/pageinspect/Makefile b/contrib/pageinspect/Makefile index 5c0736564a..31d7b1c581 100644 --- a/contrib/pageinspect/Ma

Re: Parameter for planner estimate of recursive queries

On Tue, 25 Jan 2022 at 14:44, Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 31.12.21 15:10, Simon Riggs wrote: > >> The factor 10 is a reasonably safe assumption and helps avoid worst > >> case behavior in bigger graph queries. However, the factor 10 is way > >> too large for

Re: psql crash while executing core regression tests

I use CentOS 7 with flex 2.5.37 quite extensively have never come across a psql crash. This seems more like an environment related issue on your system. On Tue, Mar 2, 2021 at 1:53 PM walker wrote: > hi > > During installation from source code, there are many crashes for psql > while

Re: Bug in error reporting for multi-line JSON

Updated the patch based on feedback. The new status of this patch is: Needs review

Re: Use boolean array for nulls parameters

I personally don't see any benefit in this change. The focus shouldn't be on fixing things that aren't broken. Perhaps, there is more value in using bitmap data type to keep track of NULL values, which is typical storage vs performance debate, and IMHO, it's better to err on using slightly more

Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested The patch looks good to me. With regards to the code comments, I had

Re: Remove unnecessary else branch

On Tue, Oct 13, 2020 at 6:37 PM Heikki Linnakangas wrote: > On 13/10/2020 16:30, Li Japin wrote: > > Hi, > > > > I found in guc-file.l we can omit the else branch in > AbsoluteConfigLocation(). > > It will compile the same, so it's just a matter of code readability or > taste which style is

Re: Improved Cost Calculation for IndexOnlyScan

On Mon, Oct 12, 2020 at 3:46 PM Hamid Akhtar wrote: > > > On Tue, Sep 29, 2020 at 2:57 PM Heikki Linnakangas > wrote: > >> On 29/09/2020 11:49, Hamid Akhtar wrote: >> > So, not actually random replacement here, rather a change with >> > baserel->all

Re: Improved Cost Calculation for IndexOnlyScan

On Tue, Sep 29, 2020 at 2:57 PM Heikki Linnakangas wrote: > On 29/09/2020 11:49, Hamid Akhtar wrote: > > So, not actually random replacement here, rather a change with > > baserel->allvisfrac taken into consideration (as given below): > > > > index_random_pag

Re: Improved Cost Calculation for IndexOnlyScan

On Tue, Sep 29, 2020 at 1:08 PM Heikki Linnakangas wrote: > On 29/09/2020 10:06, Hamid Akhtar wrote: > > In one of my earlier emails [1], I mentioned that there seems to be a > > problem with how the cost for index only scans is being calculated. > > [1] > > > http

Improved Cost Calculation for IndexOnlyScan

In one of my earlier emails [1], I mentioned that there seems to be a problem with how the cost for index only scans is being calculated. [1] https://www.postgresql.org/message-id/CANugjhsnh0OBMOYc7qKcC%2BZsVvAXCeF7QiidLuFvg6zmHy1C7A%40mail.gmail.com My concern is that there seems to be a bigger

Re: fixing old_snapshot_threshold's time->xid mapping

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Patch looks good to me.

Case for Improved Costing for Index Only Scans?

While running a simple SELECT statement on a table where I expected indexonly scan to be preferred over sequential scan, the planner kept on selecting the sequential scan. Looking at the EXPLAIN output, it seemed obvious that the cost of indexonly was exceeding that of sequential scan. So the

Re: track_planning causing performance regression

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Overall, the patch works fine. However, I have a few observations: (1)

Re: track_planning causing performance regression

On Tue, Aug 18, 2020 at 8:43 PM Fujii Masao wrote: > > > Yes, I pushed the document_overhead_by_track_planning.patch, but this > > CF entry is for pgss_lwlock_v1.patch which replaces spinlocks with > lwlocks > > in pg_stat_statements. The latter patch has not been committed yet. > > Probably

Re: track_planning causing performance regression

On Mon, Aug 17, 2020 at 2:21 PM Fujii Masao wrote: > > > On 2020/07/31 21:40, Hamid Akhtar wrote: > > <https://commitfest.postgresql.org/29/2634/> > > > > On Mon, Jul 6, 2020 at 10:29 AM Fujii Masao <mailto:masao.fu...@oss.nttdata.com>> wrote: >

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

Unfortunately the latest patch doesn't apply cleanly on the master branch. Can you please share an updated one.

Re: track_planning causing performance regression

On Mon, Jul 6, 2020 at 10:29 AM Fujii Masao wrote: > > > On 2020/07/04 12:22, Pavel Stehule wrote: > > > > > > pá 3. 7. 2020 v 13:02 odesílatel Fujii Masao < > masao.fu...@oss.nttdata.com > napsal: > > > > > > > >

Re: Rethinking opclass member checks and dependency strength

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Looks good to me. CORRECTION: In my previous review I had

Re: Rethinking opclass member checks and dependency strength

On Tue, Jul 28, 2020 at 8:43 PM Tom Lane wrote: > Hamid Akhtar writes: > > I've gone through the patch and applied on the master branch, other than > a few hunks, and whether as suggested upthread, the default case for > "switch (op->number)" should throw an erro

Re: Rethinking opclass member checks and dependency strength

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: not tested Documentation:not tested I've gone through the patch and applied on the master branch, other

Re: Should we remove a fallback promotion? take 2

There have been no real objections on this patch and it seems to work. So, IMHO, the only thing that needs to be done is perhaps update the patch so that it applies clearly on the master branch. On Mon, Jul 27, 2020 at 9:31 PM Fujii Masao wrote: > > > On 2020/07/27 17:53, Hamid Akh

Re: Should we remove a fallback promotion? take 2

Applying the patch to the current master branch throws 9 hunks. AFAICT, the patch is good otherwise. On Wed, Jun 3, 2020 at 3:20 PM Fujii Masao wrote: > > > On 2020/06/03 12:06, Kyotaro Horiguchi wrote: > > At Wed, 3 Jun 2020 09:43:17 +0900, Fujii Masao < > masao.fu...@oss.nttdata.com> wrote in

Re: Improving psql slash usage help message

So are you suggesting to not fix this or do a more detailed review and assess what other psql messages can be grouped together. On Sun, Jul 12, 2020 at 8:15 PM Tom Lane wrote: > Hamid Akhtar writes: > > On Sun, Apr 26, 2020 at 1:03 AM David G. Johnston < > > david.g.johns..

Re: WIP/PoC for parallel backup

On Mon, Jul 6, 2020 at 5:24 PM Daniel Gustafsson wrote: > > On 12 Jun 2020, at 19:28, Robert Haas wrote: > > > I am sure that nobody is arguing that the patch has to be beneficial > > in all cases in order to justify applying it. However, there are > > several good arguments against proceding

Re: tar-related code in PostgreSQL

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested The patch works perfectly. The new status of this patch is: Ready

Re: WIP/PoC for parallel backup

As far I understand, parallel backup is not a mandatory performance feature, rather, one at user's discretion. This IMHO indicates that it will benefit some users and it may not others. Taking a backup is an I/O intensive workload. So by parallelizing it through multiple worker threads/processes,

Re: Should we remove a fallback promotion? take 2

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested I've applied the v2 patch on the master branch. There some hunks, but

Re: improving basebackup.c's file-reading code

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed The idea and the patch looks good to me. It makes sense to

Re: Improving psql slash usage help message

On Sun, Apr 26, 2020 at 1:03 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Sat, Apr 25, 2020 at 12:29 PM Hamid Akhtar > wrote: > >> >> "\dE" displays the list with a "List of relations" heading whereas "\det" >> dis

Improving psql slash usage help message

psql slash usage show two options for listing foreign tables. \dE[S+] [PATTERN] list foreign tables \det[+] [PATTERN] list foreign tables This seems a little odd especially when the output of both of these commands is different. postgres=# \dE+ List of relations Schema

Re: Do we need to handle orphaned prepared transactions in the server?

Thank you everyone for the detailed feedback. On Fri, Apr 17, 2020 at 5:40 AM Michael Paquier wrote: > On Thu, Apr 16, 2020 at 03:11:51PM -0400, Tom Lane wrote: > > Even if I liked the core idea, loading the functionality onto VACUUM > seems > > like a fairly horrid design choice. It's quite

Re: Do we need to handle orphaned prepared transactions in the server?

On Thu, Apr 16, 2020 at 5:20 PM Robert Haas wrote: > On Thu, Apr 16, 2020 at 4:43 AM Hamid Akhtar > wrote: > > My real question is whether vacuum should be preemptively complaining > about prepared transactions or stale replication slots rather than waiting > for transa

Re: Do we need to handle orphaned prepared transactions in the server?

This patch actually does not discard any prepared transactions and only throws a warning for each orphaned one. So, there is no behaviour change except for getting some warnings in the log or emitting some warning to a client executing a vacuum command. I hear all the criticism which I don't

Re: Do we need to handle orphaned prepared transactions in the server?

with the new names and other suggested changes. On Wed, Mar 11, 2020 at 10:43 AM Masahiko Sawada < masahiko.saw...@2ndquadrant.com> wrote: > On Mon, 2 Mar 2020 at 21:42, Hamid Akhtar wrote: > > > > Here is the v2 of the same patch after rebasing it and running it > through pgindent.

Re: BUG #16346: pg_upgrade fails on a trigger with a comment

objects are created including event triggers and materialized views (and any other db objects). This patch is good from my side. On Wed, Apr 8, 2020 at 1:10 AM Hamid Akhtar wrote: > As you have mentioned, I have verified that indeed commit 4c40b27b broke > this. > > In this parti

Re: BUG #16346: pg_upgrade fails on a trigger with a comment

As you have mentioned, I have verified that indeed commit 4c40b27b broke this. In this particular commit moves restoration of materialized views and event triggers to the last phase. Perhaps, comments should also be moved to this phase as there may comments on either of these types of objects.

Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed All good with this patch. -- Highgo Software

Re: Minor issues in .pgpass

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Tested and looks fine to me. The new status of this patch

Re: Minor issues in .pgpass

On Wed, Mar 4, 2020 at 4:54 PM Fujii Masao wrote: > > > On 2020/03/04 20:39, Hamid Akhtar wrote: > > > > > > On Tue, Mar 3, 2020 at 8:57 PM Fujii Masao <mailto:masao.fu...@oss.nttdata.com>> wrote: > > > > >

Re: Minor issues in .pgpass

On Tue, Mar 3, 2020 at 8:57 PM Fujii Masao wrote: > > > On 2020/03/03 21:38, Hamid Akhtar wrote: > > > > > > On Mon, Mar 2, 2020 at 6:07 PM Fujii Masao <mailto:masao.fu...@oss.nttdata.com>> wrote: > > > > > > > > On 2020/02/29 0

Re: Minor issues in .pgpass

On Tue, Mar 3, 2020 at 5:38 PM Hamid Akhtar wrote: > > > On Mon, Mar 2, 2020 at 6:07 PM Fujii Masao > wrote: > >> >> >> On 2020/02/29 0:46, Hamid Akhtar wrote: >> > The following review has been posted through the commitfest application: >> > m

Re: Minor issues in .pgpass

On Mon, Mar 2, 2020 at 6:07 PM Fujii Masao wrote: > > > On 2020/02/29 0:46, Hamid Akhtar wrote: > > The following review has been posted through the commitfest application: > > make installcheck-world: not tested > > Implements feature: not tested > > Spe

Re: Do we need to handle orphaned prepared transactions in the server?

Here is the v2 of the same patch after rebasing it and running it through pgindent. There are no other code changes. On Wed, Feb 19, 2020 at 8:04 PM Hamid Akhtar wrote: > All, > > Attached is version 1 of POC patch for notifying of orphaned > prepared transactions via warn

Re: Minor issues in .pgpass

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested First of all, this seems like fixing a valid issue, albeit, the probability

Re: Do we need to handle orphaned prepared transactions in the server?

, warnings are not thrown when user runs vacuumdb and relation specific vacuum. On Fri, Jan 31, 2020 at 7:02 PM Hamid Akhtar wrote: > > > On Thu, Jan 30, 2020 at 8:28 AM Craig Ringer > wrote: > >> On Thu, 30 Jan 2020 at 02:04, Hamid Akhtar >> wrote: >> > >&

Re: Do we need to handle orphaned prepared transactions in the server?

On Thu, Jan 30, 2020 at 8:28 AM Craig Ringer wrote: > On Thu, 30 Jan 2020 at 02:04, Hamid Akhtar wrote: > > > > So having seen the feedback on this thread, and I tend to agree with > most of what has been said here, I also agree that the server core isn't > really the

Re: Do we need to handle orphaned prepared transactions in the server?

So having seen the feedback on this thread, and I tend to agree with most of what has been said here, I also agree that the server core isn't really the ideal place to handle the orphan prepared transactions. Ideally, these must be handled by a transaction manager, however, I do believe that we

Re: BUG #16171: Potential malformed JSON in explain output

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I've reviewed and verified this patch and IMHO, this is

Do we need to handle orphaned prepared transactions in the server?

Hello Everyone, I have been thinking about the orphaned prepared transaction problem in PostgreSQL and pondering on ways for handling it. A prepared transaction can be left unfinished (neither committed nor rollbacked) if the client has disappeared. It can happen for various reasons including a