Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Dec 21, 2023 at 4:41 PM John Naylor wrote: > > On Thu, Dec 21, 2023 at 8:33 AM Masahiko Sawada wrote: > > > > I found the following comment and wanted to discuss: > > > > // this might be better as "iterate over nodes", plus a callback to > > RT_DUMP_NODE, > > // which should really only

Re: Optimization outcome depends on the index order

On 25/12/2023 18:36, Alexander Korotkov wrote: On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov wrote: On 22/12/2023 11:48, Alexander Korotkov wrote: > Because we must trust all predictions made by the planner, we just > choose the most trustworthy path. According to the planner logic, it

Re: Avoid computing ORDER BY junk columns unnecessarily

On Fri, Dec 22, 2023 at 2:38 AM Heikki Linnakangas wrote: > v1-0004-Omit-columns-from-final-tlist-that-were-only-need.patch > > The main patch in this series. This patch filters out the junk columns created for ORDER BY/GROUP BY, and retains the junk columns created for RowLocks. I'm afraid

Re: Track in pg_replication_slots the reason why slots conflict?

On Thu, Dec 21, 2023 at 8:21 PM Bertrand Drouvot wrote: > > On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote: > > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote: > > > I'm not entirely sure I understand the difference - just whether we add > > > one > > > new column or replace

Re: Statistics Import and Export

Hi, I finally had time to look at the last version of the patch, so here's a couple thoughts and questions in somewhat random order. Please take this as a bit of a brainstorming and push back if you disagree some of my comments. In general, I like the goal of this patch - not having statistics

Re: pread, pwrite, etc return ssize_t not int

On Mon, Dec 25, 2023 at 7:09 AM Tom Lane wrote: > Coverity whinged this morning about the following bit in > the new pg_combinebackup code: > > 644 unsignedrb; > 645 > 646 /* Read the block from the correct source, except if > dry-run. */ > 647

Re: Show WAL write and fsync stats in pg_stat_io

On Mon, Dec 25, 2023 at 04:09:34PM +0300, Nazir Bilal Yavuz wrote: > On Wed, 9 Aug 2023 at 21:52, Melanie Plageman > wrote: >> If there is any combination of BackendType and IOContext which will >> always read XLOG_BLCKSZ bytes, we could use XLOG_BLCKSZ for that row's >> op_bytes. For other

Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)

Hi, Alexander! On Mon, 25 Dec 2023 at 02:51, Alexander Korotkov wrote: > On Tue, Dec 12, 2023 at 3:22 PM Alexander Korotkov > wrote: > > > > On Mon, Dec 11, 2023 at 6:16 PM Peter Geoghegan wrote: > > > Will you be in Prague this week? If not this might have to wait. > > > > Sorry, I wouldn't

No LINGUAS file yet for pg_combinebackup

Since dc2123400, any "make" in src/bin/pg_combinebackup whines cat: ./po/LINGUAS: No such file or directory if you have selected --enable-nls. This is evidently from AVAIL_LANGUAGES := $(shell cat $(srcdir)/po/LINGUAS) I don't particularly care to see that warning until whenever it is that

Re: apply pragma system_header to python headers

I wrote: > Probably a better way is to invent a separate header "plpython_system.h" > that just includes the Python headers, to scope the pragma precisely. > (I guess it could have the fixup #defines we're wrapping those headers > in, too.) > The same idea would work in plperl. After updating

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hello! It seems like the idea of "old" snapshot is still a valid one. > Should this deal with any potential XID wraparound, too? As far as I understand in our case, we are not affected by this in any way. Vacuum in our table is not possible because of locking, so, nothing may be frozen (see

Re: Show WAL write and fsync stats in pg_stat_io

Hi, Thanks for the review and feedback on your previous reply! On Mon, 25 Dec 2023 at 09:40, Michael Paquier wrote: > > On Mon, Dec 25, 2023 at 03:20:58PM +0900, Michael Paquier wrote: > > pgstat_tracks_io_bktype() does not look correct to me. Why is the WAL > > receiver considered as

Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression

On Mon, Dec 18, 2023 at 3:01 PM Peter Eisentraut wrote: > On 11.12.23 13:22, Amul Sul wrote: > > > > create table t1 (a int, b int generated always as (a + 1) stored); > > alter table t1 add column c int, alter column b set expression as (a > > + c); > > ERROR: 42703: column "c"

Re: Proposal to include --exclude-extension Flag in pg_dump

Hi, > long options should not mess with short options, does the following > make sense to you? Yes that makes sense, a reason to keep them together is that they are of the same kind But I will update the patch accordingly. One more thing I wanted to ask is, Should I separate them in the

Re: Optimization outcome depends on the index order

On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov wrote: > On 22/12/2023 11:48, Alexander Korotkov wrote: > > > Because we must trust all predictions made by the planner, we just > > > choose the most trustworthy path. According to the planner logic, it is > > > a path with a smaller

Re: Avoid computing ORDER BY junk columns unnecessarily

On Sat, Dec 23, 2023 at 1:32 AM Tom Lane wrote: > Heikki Linnakangas writes: > > On 22/12/2023 17:24, Tom Lane wrote: > >> How much of your patchset still makes sense if we assume that we > >> can always extract the ORDER BY column values from the index? > > > That would make it much less

Re: Proposal to include --exclude-extension Flag in pg_dump

Hi On Mon, Dec 25, 2023 at 6:22 PM Ayush Vatsa wrote: > > Added a CF entry for the same https://commitfest.postgresql.org/46/4721/ > > Regards > Ayush Vatsa > Amazon Web Services (AWS) > > On Mon, 25 Dec 2023 at 15:48, Ayush Vatsa wrote: >> >> Hi PostgreSQL Community, >> Recently I have been

Re: Proposal to include --exclude-extension Flag in pg_dump

Added a CF entry for the same https://commitfest.postgresql.org/46/4721/ Regards Ayush Vatsa Amazon Web Services (AWS) On Mon, 25 Dec 2023 at 15:48, Ayush Vatsa wrote: > Hi PostgreSQL Community, > Recently I have been working on pg_dump regarding my project and wanted to > exclude an extension

Proposal to include --exclude-extension Flag in pg_dump

Hi PostgreSQL Community, Recently I have been working on pg_dump regarding my project and wanted to exclude an extension from the dump generated. I wonder why it doesn't have --exclude-extension type of support whereas --extension exists! Since I needed that support, I took the initiative to

Re: Trigger violates foreign key constraint

On 22.12.2023 14:39, Laurenz Albe wrote: Yes, that is better - shorter and avoids passive mode. Changed. Thanks. Also I don't really like "This is not considered a bug" part, since it looks like an excuse. In a way, it is an excuse, so why not be honest about it. I still think that the

Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.

On 25.12.2023 02:38, Alexander Korotkov wrote: Pushed! Thanks a lot! With the best regards! -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: pg_basebackup has an accidentaly separated help message

At Mon, 25 Dec 2023 15:42:41 +0900, Michael Paquier wrote in > On Mon, Dec 25, 2023 at 02:39:16PM +0900, Kyotaro Horiguchi wrote: > > The attached patch contains both of the above fixes. > > Good catches, let's fix them. You have noticed that while translating > these new messages, I guess?