Re: PGC_SIGHUP shared_buffers?

On 16/02/2024 10:37 pm, Thomas Munro wrote: On Fri, Feb 16, 2024 at 5:29 PM Robert Haas wrote: 3. Reserve lots of address space and then only use some of it. I hear rumors that some forks of PG have implemented something like this. The idea is that you convince the OS to give you a whole

Re: index prefetching

On 22/01/2024 1:39 am, Tomas Vondra wrote: Why we can prefer covering index  to compound index? I see only two good reasons: 1. Extra columns type do not  have comparison function need for AM. 2. The extra columns are never used in query predicate. Or maybe you don't want to include the

Re: index prefetching

On 22/01/2024 1:47 am, Tomas Vondra wrote: h, right. Well, you're right in this case we perhaps could set just one of those flags, but the "purpose" of the two places is quite different. The "prefetch" flag is fully controlled by the prefetcher, and it's up to it to change it (e.g. I can

Re: index prefetching

On 19/01/2024 2:35 pm, Tomas Vondra wrote: On 1/19/24 09:34, Konstantin Knizhnik wrote: On 18/01/2024 6:00 pm, Tomas Vondra wrote: On 1/17/24 09:45, Konstantin Knizhnik wrote: I have integrated your prefetch patch in Neon and it actually works! Moreover, I combined it with prefetch of leaf

Re: index prefetching

On 20/01/2024 12:14 am, Tomas Vondra wrote: Looks like I was not true, even if it is not index-only scan but index condition involves only index attributes, then heap is not accessed until we find tuple satisfying search condition. Inclusive index case described above

Re: index prefetching

On 18/01/2024 5:57 pm, Tomas Vondra wrote: On 1/16/24 21:10, Konstantin Knizhnik wrote: ... 4. I think that performing prefetch at executor level is really great idea and so prefetch can be used by all indexes, including custom indexes. But prefetch will be efficient only if index can

Re: index prefetching

On 18/01/2024 6:00 pm, Tomas Vondra wrote: On 1/17/24 09:45, Konstantin Knizhnik wrote: I have integrated your prefetch patch in Neon and it actually works! Moreover, I combined it with prefetch of leaf pages for IOS and it also seems to work. Cool! And do you think this is the right design

Re: index prefetching

I have integrated your prefetch patch in Neon and it actually works! Moreover, I combined it with prefetch of leaf pages for IOS and it also seems to work. Just small notice: you are reporting `blks_prefetch_rounds` in explain, but it is not incremented anywhere. Moreover, I do not precisely

Re: index prefetching

On 16/01/2024 11:58 pm, Jim Nasby wrote: On 1/16/24 2:10 PM, Konstantin Knizhnik wrote: Amazon RDS is just vanilla Postgres with file system mounted on EBS (Amazon  distributed file system). EBS provides good throughput but larger latencies comparing with local SSDs. I am not sure if read

Re: index prefetching

On 16/01/2024 11:58 pm, Jim Nasby wrote: On 1/16/24 2:10 PM, Konstantin Knizhnik wrote: Amazon RDS is just vanilla Postgres with file system mounted on EBS (Amazon  distributed file system). EBS provides good throughput but larger latencies comparing with local SSDs. I am not sure if read

Re: index prefetching

On 16/01/2024 6:25 pm, Tomas Vondra wrote: On 1/16/24 09:13, Konstantin Knizhnik wrote: Hi, On 12/01/2024 6:42 pm, Tomas Vondra wrote: Hi, Here's an improved version of this patch, finishing a lot of the stuff that I alluded to earlier - moving the code from indexam.c, renaming a bunch

Re: Custom explain options

On 16/01/2024 5:38 pm, Tomas Vondra wrote: By "broken" you mean that you prefetch items only from a single leaf page, so immediately after reading the next one nothing is prefetched. Correct? Yes, exactly. It means that reading first heap page from next leaf page will be done without

Re: index prefetching

Hi, On 12/01/2024 6:42 pm, Tomas Vondra wrote: Hi, Here's an improved version of this patch, finishing a lot of the stuff that I alluded to earlier - moving the code from indexam.c, renaming a bunch of stuff, etc. I've also squashed it into a single patch, to make it easier to review. I am

Re: Custom explain options

On 15/01/2024 5:08 pm, Tomas Vondra wrote: My patch does not care about prefetching internal index pages. Yes, it's a limitation, but my assumption is the internal pages are maybe 0.1% of the index, and typically very hot / cached. Yes, if the index is not used very often, this may be untrue.

Re: Custom explain options

On 14/01/2024 11:47 pm, Tomas Vondra wrote: The thing that was not clear to me is who decides what to prefetch, which code issues the prefetch requests etc. In the github links you shared I see it happens in the index AM code (in nbtsearch.c). It is up to the particular plan node (seqscan,

Re: Custom explain options

On 13/01/2024 4:51 pm, Tomas Vondra wrote: On 1/12/24 20:30, Konstantin Knizhnik wrote: On 12/01/2024 7:03 pm, Tomas Vondra wrote: On 10/21/23 14:16, Konstantin Knizhnik wrote: Hi hackers, EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...) which help to provide

Re: Custom explain options

On 12/01/2024 7:03 pm, Tomas Vondra wrote: On 10/21/23 14:16, Konstantin Knizhnik wrote: Hi hackers, EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...) which help to provide useful details of query execution. In Neon we have added PREFETCH option which shows

Re: Custom explain options

On 09/01/2024 10:33 am, vignesh C wrote: On Sat, 21 Oct 2023 at 18:34, Konstantin Knizhnik wrote: Hi hackers, EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...) which help to provide useful details of query execution. In Neon we have added PREFETCH option which shows

Re: Custom explain options

On 10/01/2024 8:29 am, Andrei Lepikhov wrote: On 30/11/2023 22:40, Konstantin Knizhnik wrote: In all this cases we are using array of `Instrumentation` and if it contains varying part, then it is not clear where to place it. Yes, there is also code which serialize and sends instrumentations

Re: Custom explain options

On 10/01/2024 8:46 am, Michael Paquier wrote: On Wed, Jan 10, 2024 at 01:29:30PM +0700, Andrei Lepikhov wrote: What do you think about this really useful feature? Do you wish to develop it further? I am biased here. This seems like a lot of code for something we've been delegating to the

Re: Custom explain options

On 30/11/2023 5:59 am, Andrei Lepikhov wrote: On 21/10/2023 19:16, Konstantin Knizhnik wrote: EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...) which help to provide useful details of query execution. In Neon we have added PREFETCH option which shows information about

Custom explain options

Hi hackers, EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...) which help to provide useful details of query execution. In Neon we have added PREFETCH option which shows information about page prefetching during query execution (prefetching is more critical for Neon

Re: Can concurrent create index concurrently block each other?

On 15/10/2023 10:59 pm, Tom Lane wrote: Konstantin Knizhnik writes: One our customer complains that he spawned two `create index concurrently` for two different tables and both stuck in"waiting for old snapshots". I wonder if two CIC can really block each other in `WaitForOlde

Can concurrent create index concurrently block each other?

One our customer complains that he spawned two `create index concurrently` for two different tables and both stuck in"waiting for old snapshots". I wonder if two CIC can really block each other in `WaitForOlderSnapshots`? I found the similar question in hacker archive:

Re: Index range search optimization

On 04/10/2023 3:00 am, Alexander Korotkov wrote: On Wed, Oct 4, 2023 at 12:59 AM Pavel Borisov wrote: I've looked through the patch v8. I think it's good enough to be pushed if Peter has no objections. Thank you, Pavel. I'll push this if there are no objections. -- Regards, Alexander

Re: Support prepared statement invalidation when result types change

On 25.08.2023 8:57 PM, Jelte Fennema wrote: The cached plan for a prepared statements can get invalidated when DDL changes the tables used in the query, or when search_path changes. When this happens the prepared statement can still be executed, but it will be replanned in the new context.

Sync scan & regression tests

Hi hackers, Is it is ok, that regression tests do not pass with small value of shared buffers (for example 1Mb)? Two tests are failed because of sync scan - this tests cluster.sql and portals.sql perform seqscan without explicit order by and expect that data will be returned in particular

One more problem with JIT

Hi hackers, I am using pg_embedding extension for Postgres which implements HNSW index (some kind of ANN search). Search query looks something like this:     SELECT _id FROM documents ORDER BY openai <=> ARRAY[0.024466066, -0.00042, -0.0012917554,... , -0.008700027] LIMIT 1; I do not

Index range search optimization

Hi hackers. _bt_readpage performs key check for each item on the page trying to locate upper boundary. While comparison of simple integer keys are very fast, comparison of long strings can be quite expensive. We can first make check for the largest key on the page and if it is not larger than

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 12:04 PM, Hannu Krosing wrote: So a fair bit of work but also a clearly defined benefits of 1) reduced memory usage 2) no need to rebuild caches for each new connection 3) no need to track PREPARE statements inside connection poolers. Shared plan cache (not only prepared

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 11:41 AM, James Addison wrote: On Thu, 15 Jun 2023 at 08:12, Konstantin Knizhnik wrote: On 15.06.2023 1:23 AM, James Addison wrote: On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: On 12.06.2023 3:23 PM, Pavel Borisov wrote: Is the following true or not? 1

Re: Bypassing shared_buffers

On 15.06.2023 4:37 AM, Vladimir Churyukin wrote: Ok, got it, thanks. Is there any alternative approach to measuring the performance as if the cache was empty? The goal is basically to calculate the max possible I/O time for a query, to get a range between min and max timing. It's ok if it's

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 1:23 AM, James Addison wrote: On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: On 12.06.2023 3:23 PM, Pavel Borisov wrote: Is the following true or not? 1. If we switch processes to threads but leave the amount of session local variables unchanged, there would

Re: Let's make PostgreSQL multi-threaded

On 13.06.2023 11:46 AM, Kyotaro Horiguchi wrote: So we can assume that catalog  and relation cache should always fit in memory memory (otherwise significant rewriting of all Postgtres code working with relations will be needed). I'm not sure that is ture.. But likely to be? Sorry, looks

Re: Let's make PostgreSQL multi-threaded

On 13.06.2023 10:55 AM, Kyotaro Horiguchi wrote: At Tue, 13 Jun 2023 09:55:36 +0300, Konstantin Knizhnik wrote in Postgres backend is "thick" not because of large number of local variables. It is because of local caches: catalog cache, relation cache, prepared statem

Re: Let's make PostgreSQL multi-threaded

On 12.06.2023 3:23 PM, Pavel Borisov wrote: Is the following true or not? 1. If we switch processes to threads but leave the amount of session local variables unchanged, there would be hardly any performance gain. 2. If we move some backend's local variables into shared memory then the

Re: Named Prepared statement problems and possible solutions

On 08.06.2023 6:18 PM, Dave Cramer wrote: On Thu, 8 Jun 2023 at 11:15, Jan Wieck wrote: On 6/8/23 10:56, Dave Cramer wrote: > > > > > On Thu, 8 Jun 2023 at 10:31, Jan Wieck > wrote: > >     On 6/8/23 09:53, Jan Wieck wrote: >     

Re: Let's make PostgreSQL multi-threaded

On 07.06.2023 3:53 PM, Robert Haas wrote: I think I remember a previous conversation with Andres where he opined that thread-local variables are "really expensive" (and I apologize in advance if I'm mis-remembering this). Now, Andres is not a man who accepts a tax on performance of any size

Re: Named Prepared statement problems and possible solutions

On 08.06.2023 3:43 PM, Jan Wieck wrote: On 6/8/23 02:15, Konstantin Knizhnik wrote: There is a PR with support of prepared statement support to pgbouncer: https://github.com/pgbouncer/pgbouncer/pull/845 any feedback, reviews and suggestions are welcome. I was about to say that the support

Re: Named Prepared statement problems and possible solutions

On 07.06.2023 10:48 PM, Dave Cramer wrote: Greetings, At pgcon last week I was speaking to some people about the problem we have with connection pools and named prepared statements. For context pgjdbc (and others) use un-named statements and then switch to named statements after using the

Re: Let's make PostgreSQL multi-threaded

On 06.06.2023 5:13 PM, Robert Haas wrote: On Tue, Jun 6, 2023 at 9:40 AM Robert Haas wrote: I'm not sure that there's a strong consensus, but I do think it's a good idea. Let me elaborate on this a bit. Not all databases have this problem, and PostgreSQL isn't going to be able to stop

Re: Let's make PostgreSQL multi-threaded

On 06.06.2023 12:07 AM, Jonah H. Harris wrote: On Mon, Jun 5, 2023 at 8:18 AM Tom Lane wrote: For the record, I think this will be a disaster.  There is far too much code that will get broken, largely silently, and much of it is not under our control. While I've long been

Re: Memory leak from ExecutorState context?

On 21.04.2023 1:51 AM, Melanie Plageman wrote: On Thu, Apr 20, 2023 at 12:42 PM Konstantin Knizhnik wrote: On 11.04.2023 8:14 PM, Jehan-Guillaume de Rorthais wrote: On Sat, 8 Apr 2023 02:01:19 +0200 Jehan-Guillaume de Rorthais wrote: On Fri, 31 Mar 2023 14:06:11 +0200 Jehan-Guillaume de

Re: Memory leak from ExecutorState context?

On 11.04.2023 8:14 PM, Jehan-Guillaume de Rorthais wrote: On Sat, 8 Apr 2023 02:01:19 +0200 Jehan-Guillaume de Rorthais wrote: On Fri, 31 Mar 2023 14:06:11 +0200 Jehan-Guillaume de Rorthais wrote: [...] After rebasing Tomas' memory balancing patch, I did some memory measures to answer

OOM in hash join

Hi hackers, Too small value of work_mem cause memory overflow in parallel hash join because of too much number batches. There is the plan: explain SELECT * FROM solixschema.MIG_50GB_APR04_G1_H a join solixschema.MIG_50GB_APR04_G2_H b on a.seq_pk = b.seq_pk join

Parallel plan cost

Hi hackers, I wonder why while calculating cost of parallel scan we divide by parallel_divisor only CPU run cost, but not storage access cost? So we do not take in account that reading pages is also performed in parallel. Actually I observed strange behavior when increasing work_mem disables

Speed-up shared buffers prewarming

Hi hackers, It is well known fact that queries using sequential scan can not be used to prewarm cache, because them are using ring buffer even if shared buffers are almost empty. I have searched hackers archive but failed to find any discussion about it. What are the drawbacks of using free

Index-only scan and random_page_cost

Hi hackers, Right now cost of index-only scan is using `random_page_cost`. Certainly for point selects we really have random access pattern, but queries like "select count(*) from hits"  access pattern is more or less sequential: we are iterating through subsequent leaf B-Tree pages.  As far

Re: Lack of PageSetLSN in heap_xlog_visible

On 11.11.2022 03:20, Jeff Davis wrote: On Thu, 2022-10-13 at 12:49 -0700, Jeff Davis wrote: It may violate our torn page protections for checksums, as well... I could not reproduce a problem here, but I believe one exists when checksums are enabled, because it bypasses the protections of

Lack of PageSetLSN in heap_xlog_visible

Hi hackers! heap_xlog_visible is not bumping heap page LSN when setting all-visible flag in it. There is long comment explaining it:    /*     * We don't bump the LSN of the heap page when setting the visibility     * map bit (unless checksums or wal_hint_bits is enabled, in

Re: SLRUs in the main buffer pool, redux

On 28.05.2022 04:13, Thomas Munro wrote: On Fri, May 27, 2022 at 11:24 PM Thomas Munro wrote: Rebased, debugged and fleshed out a tiny bit more, but still with plenty of TODO notes and questions. I will talk about this idea at PGCon, so I figured it'd help to have a patch that actually

Race condition in TransactionIdIsInProgress

Hi hackers, Postgres first records state transaction in CLOG, then removes transaction from procarray and finally releases locks. But it can happen that transaction is marked as committed in CLOG, XMAX_COMMITTED bit is set in modified tuple but TransactionIdIsInProgress still returns true. As

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

On 11.01.2022 03:06, Bossart, Nathan wrote: I noticed this thread and thought I'd share my experiences building something similar for Multi-AZ DB clusters [0]. It's not a strict RPO mechanism, but it does throttle backends in an effort to keep the replay lag below a configured maximum. I

Re: Add ZSON extension to /contrib/

On 25.05.2021 13:55, Aleksander Alekseev wrote: Hi hackers, Back in 2016 while being at PostgresPro I developed the ZSON extension [1]. The extension introduces the new ZSON type, which is 100% compatible with JSONB but uses a shared dictionary of strings most frequently used in given

Re: Built-in connection pooler

Hi, Thank you for review! On 21.03.2021 23:59, Zhihong Yu wrote: Hi, +          With load-balancing policy postmaster choose proxy with lowest load average. +          Load average of proxy is estimated by number of clients connection assigned to this proxy with extra weight for SSL

Re: Built-in connection pooler

People asked me to resubmit built-in connection pooler patch to commitfest. Rebased version of connection pooler is attached. diff --git a/contrib/spi/refint.c b/contrib/spi/refint.c index 6fbfef2b12..27aa6cba8e 100644 --- a/contrib/spi/refint.c +++ b/contrib/spi/refint.c @@ -11,6 +11,7 @@

Re: Columns correlation and adaptive query optimization

able "cols" is NULL and we always take first branch of the if. In other words, at each iteration of outer loop we always make some progress in processing "vars" list and remove some elements from this list. So infinite loop can never happen. Cheers On Fri, Mar 19, 2021

Re: Columns correlation and adaptive query optimization

On 19.03.2021 12:17, Yugo NAGATA wrote: On Wed, 10 Mar 2021 03:00:25 +0100 Tomas Vondra wrote: What is being proposed here - an extension suggesting which statistics to create (and possibly creating them automatically) is certainly useful, but I'm not sure I'd call it "adaptive query

Re: Improve join selectivity estimation using extended statistics

On 11.03.2021 03:47, Tomas Vondra wrote: Hi Konstantin, Thanks for working on this! Using extended statistics to improve join cardinality estimates was definitely on my radar, and this patch seems like a good start. I had two basic ideas about how we might improve join estimates: (a) use

Re: Improving connection scalability: GetSnapshotData()

On 27.02.2021 20:40, AJG wrote: Hi, Greatly appreciate if you could please reply to the following questions as time allows. I have seen previous discussion/patches on a built-in connection pooler. How does this scalability improvement, particularly idle connection improvements etc, affect

Re: libpq compression

On 22.02.2021 08:38, Craig Ringer wrote: On Thu, 11 Feb 2021, 21:09 Daniil Zakhlystov, mailto:usernam...@yandex-team.ru>> wrote:: 3. Chunked compression allows to compress only well compressible messages and save the CPU cycles by not compressing the others 4. Chunked

Re: libpq compression

On 22.02.2021 23:44, Tom Lane wrote: Robert Haas writes: So at the end of the day I'm not really quite sure what is best here. I agree with all of Craig's points about the advantages of packet-level compression, so I'd really prefer to make that approach work if we can. However, it also

Re: Problem with accessing TOAST data in stored procedures

On 19.02.2021 11:12, Pavel Stehule wrote: pá 19. 2. 2021 v 9:08 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 19.02.2021 10:47, Pavel Stehule wrote: pá 19. 2. 2021 v 8:39 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgres

Re: [PoC] Non-volatile WAL buffer

Thank you for your feedback. On 19.02.2021 6:25, Tomas Vondra wrote: On 1/22/21 5:04 PM, Konstantin Knizhnik wrote: ... I have heard from several DBMS experts that appearance of huge and cheap non-volatile memory can make a revolution in database system architecture. If all database can fit

Re: Problem with accessing TOAST data in stored procedures

On 19.02.2021 10:47, Pavel Stehule wrote: pá 19. 2. 2021 v 8:39 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 19.02.2021 10:14, Pavel Stehule wrote: pá 19. 2. 2021 v 7:51 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgres

Re: Problem with accessing TOAST data in stored procedures

On 19.02.2021 10:14, Pavel Stehule wrote: pá 19. 2. 2021 v 7:51 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 18.02.2021 20:10, Pavel Stehule wrote: This has a negative impact on performance - and a lot of users use procedures w

Re: Problem with accessing TOAST data in stored procedures

) -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Problem with accessing TOAST data in stored procedures

INTO toasted(data) VALUES((SELECT string_agg(random()::text,':') FROM generate_series(1, 1000))); DO $$ DECLARE v_r record; BEGIN FOR v_r in SELECT data FROM toasted LOOP INSERT INTO toasted(data) VALUES(v_r.data);COMMIT;END LOOP;END;$$; -- Konstantin Knizhnik Postgres Professional: http

Re: Problem with accessing TOAST data in stored procedures

On 19.08.2020 22:20, Pavel Stehule wrote: st 19. 8. 2020 v 20:59 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 19.08.2020 21:50, Pavel Stehule wrote: Hi st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik mailto:k

Re: libpq compression

On 11.02.2021 16:09, Daniil Zakhlystov wrote: Hi! On 09.02.2021 09:06, Konstantin Knizhnik wrote: Sorry, but my interpretation of your results is completely different: permanent compression is faster than chunked compression (2m15 vs. 2m27) and consumes less CPU (44 vs 48 sec). Size of RX

Re: libpq compression

to control compression on the fly and use different compression algorithm for TX/RX data just complicates implementation and given no significant advantages. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: On login trigger: take three

atch, I am afraid that we might lose track of this unless we register it. Yes, certainly: https://commitfest.postgresql.org/31/2900/ -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Improve join selectivity estimation using extended statistics

in the clausesel patch. Sorry, do not have idea right now how to use MCV for better estimation of join selectivity. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/optimizer/path/clausesel.c b/src/backend/optimizer/path

Re: Columns correlation and adaptive query optimization

On 27.01.2021 8:45, Yugo NAGATA wrote: On Mon, 25 Jan 2021 16:27:25 +0300 Konstantin Knizhnik wrote: Hello, Thank you for review. My answers are inside. Thank you for updating the patch and answering my questions. (2) If I understand correctly, your proposal consists of the following

Re: Columns correlation and adaptive query optimization

Hello, Thank you for review. My answers are inside. On 21.01.2021 15:30, Yugo NAGATA wrote: Hello, On Thu, 26 Mar 2020 18:49:51 +0300 Konstantin Knizhnik wrote: Attached please find new version of the patch with more comments and descriptions added. Adaptive query optimization is very

Re: [PoC] Non-volatile WAL buffer

uence is actually ready WAL records. So implementors of access methods do not have to do double work: update data structure in memory and create correspondent WAL records. Moreover, PMwCAS operations are atomic: we can replay or revert them in case of fault. So there is no need in FPW (full page writes

Re: libpq compression

On 12.01.2021 18:38, Justin Pryzby wrote: On Tue, Jan 12, 2021 at 08:44:43AM +0300, Konstantin Knizhnik wrote: On 11.01.2021 20:38, Tomas Vondra wrote: 1) Fixes the MSVC makefile. The list of files is sorted alphabetically, so I've added the file at the end. Thank you This is still

Re: libpq compression

On 12.01.2021 4:20, Justin Pryzby wrote: On Mon, Jan 11, 2021 at 04:53:51PM +0300, Konstantin Knizhnik wrote: On 09.01.2021 23:31, Justin Pryzby wrote: I suggest that there should be an enum of algorithms, which is constant across all servers. They would be unconditionally included

Re: libpq compression

On 11.01.2021 20:38, Tomas Vondra wrote: On 1/11/21 2:53 PM, Konstantin Knizhnik wrote: ... New version of libpq compression patch is attached. It can be also be found at g...@github.com:postgrespro/libpq_compression.git Seems it bit-rotted already, so here's a slightly fixed version. 1

Re: libpq compression

On 09.01.2021 23:31, Justin Pryzby wrote: On Thu, Dec 17, 2020 at 05:54:28PM +0300, Konstantin Knizhnik wrote: I am maintaining this code in g...@github.com:postgrespro/libpq_compression.git repository. I will be pleased if anybody, who wants to suggest any bug fixes/improvements of libpq

Re: On login trigger: take three

On 22.12.2020 21:19, Pavel Stehule wrote: út 22. 12. 2020 v 12:42 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 22.12.2020 12:25, Pavel Stehule wrote: regress tests fails      sysviews                     ... FAILED    112 ms

Re: libpq compression

On 22.12.2020 22:03, Tom Lane wrote: Tomas Vondra writes: I don't see aby benchmark results in this thread, allowing me to make that conclusion, and I find it hard to believe that 200MB/client is a sensible trade-off. It assumes you have that much memory, and it may allow easy DoS attack

Re: On login trigger: take three

                       ... FAILED      626 ms == shutting down postmaster == Sorry, fixed. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml index 036a72c..bb62f25

Inconsistent/confusing handling of tablespaces for partitioned tables

other tablepsace. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: On login trigger: take three

On 20.12.2020 10:04, Pavel Stehule wrote: čt 17. 12. 2020 v 19:30 odesílatel Pavel Stehule mailto:pavel.steh...@gmail.com>> napsal: čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 17.12.2020 9:31, P

Re: Double partition lock in bufmgr

On 19.12.2020 10:53, Zhihong Yu wrote: Hi, w.r.t. the code in BufferAlloc(), the pointers are compared. Should we instead compare the tranche Id of the two LWLock ? Cheers As far as LWlocks are stored in the array, comparing indexes in this array (tranche Id) is equivalent to comparing

Double partition lock in bufmgr

he past  faced with the similar symptoms and was this problem with holding locks of two partitions in bufmgr already discussed? P.S. The customer is using 9.6 version of Postgres, but I have checked that the same code fragment is present in the master. -- Konstantin Knizhnik Postgres Professional

Re: libpq compression

). I am maintaining this code in g...@github.com:postgrespro/libpq_compression.git repository. I will be pleased if anybody, who wants to suggest any bug fixes/improvements of libpq compression, create pull requests: it will be much easier for me to merge them. -- Konstantin Knizhnik Postgres

Re: On login trigger: take three

e too long). Thank you, fixed. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: On login trigger: take three

connection_trigger. New version of the patch is attached. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f810789..45d30b3 100644 --- a/doc/src/sgml/config.sgml +++

Re: On login trigger: take three

flag is never cleaned (to avoid visibility issues mentioned in my previous mail). -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/event-trigger.sgml b/doc/src/sgml/event-trigger.sgml index 60366a9..00f69b8 100644 -

Re: On login trigger: take three

On 15.12.2020 18:25, Pavel Stehule wrote: út 15. 12. 2020 v 15:06 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 15.12.2020 16:18, Pavel Stehule wrote: út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgres

Re: On login trigger: take three

On 15.12.2020 16:18, Pavel Stehule wrote: út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 11.12.2020 19:27, Pavel Stehule wrote: pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgres

Re: On login trigger: take three

On 11.12.2020 19:27, Pavel Stehule wrote: pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 11.12.2020 18:40, Pavel Stehule wrote: is not correct. It makes it not possible to superuser to disable triggers f

Re: On login trigger: take three

s GUC check. And this option should be defined with PGC_SU_BACKEND -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: On login trigger: take three

On 10.12.2020 21:09, Pavel Stehule wrote: čt 10. 12. 2020 v 16:48 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 10.12.2020 18:12, Pavel Stehule wrote: My idea was a little bit different. Inside postinit initialize some global var

Re: On login trigger: take three

On 10.12.2020 18:12, Pavel Stehule wrote: My idea was a little bit different. Inside postinit initialize some global variables with info if there are event triggers or not. And later you can use this variable to start transactions and  other things. There will be two access to

Re: On login trigger: take three

On 10.12.2020 10:45, Pavel Stehule wrote: st 9. 12. 2020 v 14:28 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 09.12.2020 15:34, Pavel Stehule wrote: Hi st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow mailto:gregn4...@gmail.com>

Re: On login trigger: take three

5383 (excluding connections establishing) As you can see - there is almost now different (patched version is even faster, but it seems to be just "white noise". -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Wrong check in pg_visibility?

On 06.12.2020 23:50, Konstantin Knizhnik wrote: Hi hackers! Due to the error in PG-ProEE we have added the following test to pg_visibility: create table vacuum_test as select 42 i; vacuum vacuum_test; select count(*) > 0 from pg_check_visible('vacuum_test'); drop table vacuum_t

  1   2   3   4   5   6   7   >