Re: Use generation memory context for tuplestore.c

On Sat, 4 May 2024 at 03:51, Matthias van de Meent wrote: > > On Fri, 3 May 2024 at 15:55, David Rowley wrote: > > master @ 8f0a97dff > > Storage: Memory Maximum Storage: 16577kB > > > > patched: > > Storage: Memory Maximum Storage: 8577kB > > Those are some impressive numbers. This patch need

Cluster forcefully removal without user input

Hello, I have installed PostgreSQL 15 and PostgreSQL 14 side by side and want to upgrade from 14 to 15. For upgrading purposes, I am using {postgresql-15-setup check_upgrade}. However, in my case, the installed 14 version is not compatible with the latest 15.7. After the installation and cluster

Explicit specification of index ensuring uniqueness of foreign columns

I'd like to resurrect a subset of my proposal in [1], specifically that: The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ] clause optionally following the referenced column list. The index specified by this clause is used to support the foreign key constraint, and it mu

Re: Add memory context type to pg_backend_memory_contexts view

On Fri, 31 May 2024 at 07:21, David Christensen wrote: > Giving this a once-through, this seems straightforward and useful. I > have a slight preference for keeping "name" the first field in the > view and moving "type" to the second, but that's minor. Not having it first make sense, but I don't

Re: POC: GROUP BY optimization

Hi! On Thu, May 30, 2024 at 7:22 AM Andrei Lepikhov wrote: > On 5/29/24 19:53, Alexander Korotkov wrote: > > Thank you for your feedback. > > > > On Wed, May 29, 2024 at 11:08 AM Andrei Lepikhov > > wrote: > >> On 5/27/24 19:41, Alexander Korotkov wrote: > >>> Any thoughts? > >> About 0001: > >>

Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)

Hello, I am looking through some outstanding CommitFest entries; I wonder if this particular patch is already effectively fixed by 5278d0a2, which is both attributed to the original author as well as an extremely similar approach. Can this entry (https://commitfest.postgresql.org/48/4553/) be clo

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote: > [ cut ] > > I have rebased master and fixed a plan diff case. We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch at PgConf.dev Patch Review Workshop. Here are our findings. Patch tries to allow for using materialization together w

Re: Add memory context type to pg_backend_memory_contexts view

Hi David, Giving this a once-through, this seems straightforward and useful. I have a slight preference for keeping "name" the first field in the view and moving "type" to the second, but that's minor. Just confirming that the allocator types are not extensible without a recompile, since it's us

Re: Vacuum statistics

Hi, Th, 30/05/2024 at 10:33 -0700, Alena Rybakina wrote: > I suggest gathering information about vacuum resource consumption for > processing indexes and tables and storing it in the table and index > relationships (for example, PgStat_StatTabEntry structure like it has > realized for usual stati

Re: Vacuum statistics

On 30.05.2024 10:33, Alena Rybakina wrote: I suggest gathering information about vacuum resource consumption for processing indexes and tables and storing it in the table and index relationships (for example, PgStat_StatTabEntry structure like it has realized for usual statistics). It will al

Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)

Hi Justin, Thanks for the patch and the work on it. In reviewing the basic feature, I think this is something that has utility and is worthwhile at the high level. A few more specific notes: The pg_namespace_size() function can stand on its own, and probably has some utility for the released Po

Vacuum statistics

Hello, everyone! I think we don't have enough information to analyze vacuum functionality. Needless to say that the vacuum is the most important process for a database system. It prevents problems like table and index bloating and emergency freezing if we have a wraparound problem. Furthermore

Re: The xversion-upgrade test fails to stop server

Sent from my iPhone > On May 30, 2024, at 8:00 AM, Alexander Lakhin wrote: > > Hello Andrew, > > While reviewing recent buildfarm failures, I came across this one: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-05-23%2004%3A11%3A03 > > upgrade.crake/REL_16_STABLE/RE

Re: Add LSN <-> time conversion functionality

Hi everyone! Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we got everything wrong, please consider that we are just doing training on reviewing patches. === Purpose of the patch === Currently, we have checkpoint_timeout and max_wal size to know when we need a c

Re: meson "experimental"?

On Thu, May 30, 2024 at 6:32 AM Aleksander Alekseev < aleksan...@timescale.com> wrote: > > > By a quick look on the buildfarm we seem to use Ninja >= 1.11.1. > However since Meson can use both Ninja and VS as a backend I'm not > certain which section would be most appropriate for naming the minima

The xversion-upgrade test fails to stop server

Hello Andrew, While reviewing recent buildfarm failures, I came across this one: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-05-23%2004%3A11%3A03 upgrade.crake/REL_16_STABLE/REL9_5_STABLE-ctl4.log waiting for server to shut down.

Re: Implementing CustomScan over an index

Hi, > So I started implementing a CustomScan. It's not trivial. > > I've learned that the system executes ExecInitCustomScan automatically, but I > probably need it to do most of the stuff in ExecInitIndexScan, and then > execute the scan mostly the way it's done in IndexNext. > > Basically, I w

Re: meson "experimental"?

Hi, > > [*] What is the correct name for this? > > I believe in this section it should be "Visual Studio" as we specify > elsewhere [1][2]. In [2] we name specific required versions. Maybe we > should reference this section. > > While on it, in [2] section 17.7.5 is named "Visual". I don't think >

Re: meson "experimental"?

Hi. > "Alternatively, PostgreSQL can be built using Meson. This is the only > option for building PostgreSQL in Windows using Visual Something[*]. > For other platforms, using Meson is currently experimental." +1 good catch > [*] What is the correct name for this? I believe in this section it

Re: Exposing the lock manager's WaitForLockers() to SQL

I should add that the latest patches remove permissions checks because pg_locks doesn't have any, and improve the commit messages. Hope I didn't garble anything doing this late after the dev conference. :-) Robert asked me about other existing functions that could be leveraged, such as GetConflict

Re: Exposing the lock manager's WaitForLockers() to SQL

I got some very helpful off-list feedback from Robert Haas that this needed more self-contained explanation/motivation. So here goes. :-) This patch set adds a new SQL function pg_wait_for_lockers(), which waits for transactions holding specified table locks to commit or roll back. This can be use