Re: Allow an alias to be attached directly to a JOIN ... USING

On 05.03.21 18:00, David Steele wrote: On 11/14/20 3:49 AM, Peter Eisentraut wrote: On 2020-11-10 16:15, Georgios Kokolatos wrote: I noticed that this patch fails on the cfbot. For this, I changed the status to: 'Waiting on Author'. Cheers, //Georgios The new status of this patch is: Waitin

RE: Parallel Inserts in CREATE TABLE AS

From: Bharath Rupireddy >I analyzed performance of parallel inserts in CTAS for different cases >with tuple size 32bytes, 59bytes, 241bytes and 1064bytes. We could >gain if the tuple sizes are lower. But if the tuple size is larger >i..e 1064bytes, there's a regression with parallel inserts. Than

Re: About to add WAL write/fsync statistics to pg_stat_wal view

On 2021/03/15 10:39, Masahiro Ikeda wrote: Thanks, I understood get_sync_bit() checks the sync flags and the write unit of generated wal data and replicated wal data is different. (It's interesting optimization whether to use kernel cache or not.) OK. Although I agree to separate the stats fo

Re: Parallel Inserts in CREATE TABLE AS

On Fri, Mar 19, 2021 at 12:45 PM tanghy.f...@fujitsu.com wrote: > > From: Bharath Rupireddy > >I analyzed performance of parallel inserts in CTAS for different cases > >with tuple size 32bytes, 59bytes, 241bytes and 1064bytes. We could > >gain if the tuple sizes are lower. But if the tuple size i

Re: fdatasync performance problem with large number of DB files

On 2021/03/19 14:28, Thomas Munro wrote: On Fri, Mar 19, 2021 at 3:23 PM Fujii Masao wrote: Thanks for updating the patch! It looks good to me! I have one minor comment for the patch. + elog(LOG, "could not open %s: %m", path); + return; + } + if (syn

RE: libpq debug log

Hi Tsunakawa san, Thank you for your review. I update patch to v29. Output is following. It is fine. ``` 2021-03-19 07:21:09.917302 > 4 Terminate 2021-03-19 07:21:09.961494 > 155 Query"CREATE TABLESPACE regress_tblspacewith LOCATION '/home/iwata/pg

Re: Disable WAL logging to speed up data loading

On Fri, 2021-03-19 at 06:53 +, tsunakawa.ta...@fujitsu.com wrote: > From: David Steele > > After reading through the thread (but not reading the patch) I am -1 on > > this proposal. > > > > The feature seems ripe for abuse and misunderstanding, and as has been > > noted in the thread, there a

RE: libpq debug log

Alvaro-san, Iwata-san, cc: Tom-san, Horiguchi-san, Thank you, it finally looks complete to me! Alvaro-san, We appreciate your help and patience, sometimes rewriting large part of the patch. Could you do the final check (and possibly tweak) for commit? Regards Takayuki Tsunakawa

Re: Proposal: Save user's original authenticated identity for logging

On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote: > Looking at 0001, I am not much a fan of relying on the position of the > matching pattern in the log file. Instead of relying on the logging > collector and one single file, why not just changing the generation of > the logfile and

RE: Disable WAL logging to speed up data loading

From: Laurenz Albe > Now I'm not saying that this feature should not go in (I set it to > "ready for committer", because I see no technical flaw with the > implementation), but it remains debatable if we want the feature or not. Oh, yes, thank you very much for supporting this and other relevant

Re: Reduce the time required for a database recovery from archive.

Hello everyone in this thread! On 2021-03-18 18:04, David Steele wrote: Seems like there should have been a patch attached? IMO there's a technical problem with sending, receiving (or displaying on the site) emails from the list pgsql-hackers. By subsribing to this list I received the attach

RE: Parallel Inserts in CREATE TABLE AS

> They are pretty simple though. I think someone can also check if the same > regression exists for parallel inserts in "INSERT INTO SELECT" > patch set as well for larger tuple sizes. Thanks for reminding. I did some performance tests for parallel inserts in " INSERT INTO SELECT " with the testc

Re: Columns correlation and adaptive query optimization

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 optimization". I > think "adaptive" means the

Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

On 2021/03/19 15:06, shinya11.k...@nttdata.com wrote: But 0 value maybe looks strange, so in current version I show it like >below: Type N (%) Record size (%) FPI size (%) Combined size (%) - --- --- --- --- - --- ... XLOG/SWITCH_JUNK - ( -) 11006248 ( 72.26)

RE: Parallel Inserts in CREATE TABLE AS

> > They are pretty simple though. I think someone can also check if the > > same regression exists for parallel inserts in "INSERT INTO SELECT" > > patch set as well for larger tuple sizes. > > Thanks for reminding. > I did some performance tests for parallel inserts in " INSERT INTO SELECT " >

RE: invalid data in file backup_label problem on windows

Hi, David Steele wrote: > I'm not sure how I feel about this patch (not really a Windows person) > but I do think that you shouldn't modify the backup_label when writing > it, i.e. you should be writing backup_label in binary mode to avoid this > issue. IMO, I don't modify backup_lable,

Re: fdatasync performance problem with large number of DB files

On Fri, Mar 19, 2021 at 06:28:46PM +1300, Thomas Munro wrote: > +++ b/doc/src/sgml/config.sgml > +PostgreSQL will recursively open and fsync > +all files in the data directory before crash recovery begins. This Maybe it should say "data, tablespace, and WAL directories", or just

Re: Parallel Inserts in CREATE TABLE AS

On Fri, Mar 19, 2021 at 4:33 PM Bharath Rupireddy wrote: > > In an offlist discussion with Robert and Dilip, using fallocate to > extend the relation may help to extend the relation faster. In regards > to this, it looks like the AIO/DIO patch set of Andres [1] which > involves using fallocate()

Re: Reduce the time required for a database recovery from archive.

On 3/19/21 4:32 AM, Marina Polyakova wrote: On 2021-03-18 18:04, David Steele wrote: Seems like there should have been a patch attached? IMO there's a technical problem with sending, receiving (or displaying on the site) emails from the list pgsql-hackers. By subsribing to this list I recei

Re: Asynchronous Append on postgres_fdw nodes.

is_async_capable_path() should probably have a "break" for case T_ForeignPath. little typos: aready sigle givne a event: an event -- Justin

Re: Speeding up GIST index creation for tsvectors

On Thu, 11 Mar 2021 at 04:25, John Naylor wrote: > Okay, so it's hard-coded in various functions in contrib modules. In that > case, let's just keep the existing coding for those. In fact, the comments > that got removed by your patch specifically say: /* Using the popcount > functions here isn't

Re: invalid data in file backup_label problem on windows

On 3/19/21 6:11 AM, wangsh.f...@fujitsu.com wrote: David Steele wrote: I'm not sure how I feel about this patch (not really a Windows person) but I do think that you shouldn't modify the backup_label when writing it, i.e. you should be writing backup_label in binary mode to avoid this issue.

Re: pl/pgsql feature request: shorthand for argument and local variable references

On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule wrote: > But we don't support this feature. We are changing just a top scope's label. > So syntax "ALIAS FOR FUNCTION is not good. The user can have false hopes In this case it looks like it should go together with other labels and have << label_her

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote: > On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote: > > On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote: > > > > The above text is the part that made me think an extension could display > > a query id even

Re: [Patch] ALTER SYSTEM READ ONLY

Hi all, While testing this feature with v20-patch, the server is crashing with below steps. Steps to reproduce: 1. Configure master-slave replication setup. 2. Connect to Slave. 3. Execute below statements, it will crash the server: SELECT pg_prohibit_wal(true); SELECT pg_prohibit_wal(false); --

Re: SQL-standard function body

On 15.03.21 09:14, Julien Rouhaud wrote: On Mon, Mar 15, 2021 at 04:03:44PM +0800, Julien Rouhaud wrote: On Mon, Mar 15, 2021 at 01:05:11AM -0500, Jaime Casanova wrote: I found another problem when using CASE expressions: CREATE OR REPLACE FUNCTION foo_case() RETURNS boolean LANGUAGE SQL BEGIN

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote: > > OK, that makes perfect sense. I think the best solution is to document > that compute_query_id just controls the built-in computation of the > query id, and that extensions can also compute it if this is off, and > pg_stat_activity and log_

Re: fdatasync performance problem with large number of DB files

On 3/19/21 1:28 AM, Thomas Munro wrote: On Fri, Mar 19, 2021 at 3:23 PM Fujii Masao wrote: Thanks for updating the patch! It looks good to me! I have one minor comment for the patch. + elog(LOG, "could not open %s: %m", path); + return; + } + if (syncfs(

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Mar-17, Justin Pryzby wrote: > The v8 patch has the "broken constraint" problem. Yeah, I had misunderstood what the problem was. I think a good solution to this is to have get_partition_parent return the true parent even when a detach is pending, for one particular callsite. (This means

Re: Allow an alias to be attached directly to a JOIN ... USING

Peter Eisentraut writes: > I think Tom's input on the guts of this patch would be most valuable, > since it intersects a lot with the parse namespace refactoring he did. Yeah, I've been meaning to take a look. I'll try to get it done in the next couple of days. regards,

[PATCH] pg_stat_statements dealloc field ignores manual deallocation

Hi, This is a proposal of a patch for pg_stat_statements extension. It corrects deallocation events accounting. Since 2e0fedf there is a view pg_stat_statements_info is available in pg_stat_statements extension. It has a dealloc field, that should be a counter of deallocation events happened. Rig

Re: support for MERGE

On 1/18/21 11:48 AM, Alvaro Herrera wrote: On 2021-Jan-18, Robert Haas wrote: On Thu, Dec 31, 2020 at 8:48 AM Alvaro Herrera wrote: Here's a rebase of Simon/Pavan's MERGE patch to current sources. I cleaned up some minor things in it, but aside from rebasing, it's pretty much their work (eve

Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation

On Fri, Mar 19, 2021 at 05:08:45PM +0300, Андрей Зубков wrote: > > Since 2e0fedf there is a view pg_stat_statements_info is available in > pg_stat_statements extension. It has a dealloc field, that should be a > counter of deallocation events happened. > Right now it accounts only automatic deallo

Re: cleanup temporary files after crash

On Fri, Mar 19, 2021, at 12:23 AM, Tom Lane wrote: > [ reads code... ] > ... no, I think the problem is the test is still full of race conditions. > > In the first place, waiting till you see the output of a SELECT that's > before the useful query is not enough to guarantee that the useful query >

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote: > On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote: > > Now that I'm back on the code I remember why I did it this way. It's > > unfortunately not really possible to make things work this way. > > > > pg_stat_statements'

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote: > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote: > > > > OK, that makes perfect sense. I think the best solution is to document > > that compute_query_id just controls the built-in computation of the > > query id, and that exten

Re: Nicer error when connecting to standby with hot_standby=off

On Tue, Mar 9, 2021 at 9:27 AM Fujii Masao wrote: > > > > On 2021/03/09 23:19, James Coleman wrote: > > On Tue, Mar 9, 2021 at 9:17 AM Alvaro Herrera > > wrote: > >> > >> On 2021-Mar-09, James Coleman wrote: > >> > >>> Yes, I think they both agreed on the "DETAIL: Hot standby mode is > >>> disa

Re: support for MERGE

On 2021-Mar-19, David Steele wrote: > Since it does not appear this is being worked on for PG14 perhaps we should > close it in this CF and then reopen it when a patch is available? No, please move it to the next CF. Thanks -- Álvaro Herrera Valdivia, Chile

Re: support for MERGE

On 3/19/21 10:44 AM, Alvaro Herrera wrote: On 2021-Mar-19, David Steele wrote: Since it does not appear this is being worked on for PG14 perhaps we should close it in this CF and then reopen it when a patch is available? No, please move it to the next CF. Thanks Ugh. I clicked wrong and mo

Re: truncating timestamps on arbitrary intervals

On 1/18/21 3:54 PM, John Naylor wrote: On Mon, Nov 23, 2020 at 1:44 PM John Naylor mailto:john.nay...@enterprisedb.com>> wrote: > > On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut > wrote: > > - After reading the discussion a few times, I'm not so

Re: default result formats setting

I applied the patch, tried running the test and got the following: rm -rf '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check /bin/sh ../../../../config/install-sh -c -d '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check cd . && TESTDIR='/U

Re: Disable WAL logging to speed up data loading

Greetings, * tsunakawa.ta...@fujitsu.com (tsunakawa.ta...@fujitsu.com) wrote: > From: David Steele > > After reading through the thread (but not reading the patch) I am -1 on > > this proposal. > > > > The feature seems ripe for abuse and misunderstanding, and as has been > > noted in the thread

Re: [PATCH] ProcessInterrupts_hook

On 1/19/21 1:42 AM, Craig Ringer wrote: On Tue, 19 Jan 2021 at 12:44, Craig Ringer mailto:craig.rin...@enterprisedb.com>> wrote: > We're about halfway there already, see 7e784d1dc.  I didn't do the > other half because it wasn't necessary to the problem, but e

Re: psql \df choose functions by their arguments

On 1/19/21 11:58 AM, Greg Sabino Mullane wrote: Ha ha ha, my bad, I am not sure why I left those out. Here is a new patch with int2, int4, and int8. Thanks for the email. Ian, does the new patch look good to you? Also, not sure why the target version for this patch is stable so I have updated

Re: Logical Replication vs. 2PC

On 18.03.21 10:45, Amit Kapila wrote: While reviewing/testing subscriber-side work for $SUBJECT [1], I noticed a problem that seems to need a broader discussion, so started this thread. We can get prepare for the same GID more than once for the cases where we have defined multiple subscriptions f

Re: create table like: ACCESS METHOD

On 1/19/21 4:03 PM, Justin Pryzby wrote: On Wed, Dec 30, 2020 at 12:33:56PM +, Simon Riggs wrote: There are no tests for the new functionality, please could you add some? Did you look at the most recent patch? +CREATE ACCESS METHOD heapdup TYPE TABLE HANDLER heap_tableam_handler; +CREATE

Re: Change default of checkpoint_completion_target

On 1/19/21 2:47 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: Any further comments or thoughts on this one? This: +total time between checkpoints. The default is 0.9, which spreads the +checkpoint across the entire checkpoint timeout

Re: cleanup temporary files after crash

On 3/19/21 3:17 PM, Euler Taveira wrote: > On Fri, Mar 19, 2021, at 12:23 AM, Tom Lane wrote: >> [ reads code... ] >> ... no, I think the problem is the test is still full of race conditions. >> >> In the first place, waiting till you see the output of a SELECT that's >> before the useful query i

Re: cleanup temporary files after crash

On 3/19/21 5:23 PM, Tomas Vondra wrote: > ... > > If I replace this with a wait loop in a plpgsql block, that works > perfectly fine (no infinite loops). Tested both on x86_64 and rpi. > For the record, here's the version with plpgsql block, which seems to be working just fine. regards -- To

Re: cleanup temporary files after crash

On 3/19/21 5:23 PM, Tomas Vondra wrote: > ... > > If I replace this with a wait loop in a plpgsql block, that works > perfectly fine (no infinite loops). Tested both on x86_64 and rpi. > For the record, here's the version with plpgsql block, which seems to be working just fine. regards -- Toma

Re: [HACKERS] Custom compression methods

I sent offlist a couple of times but notice that the latest patch is missing this bit around AC_CHECK_HEADERS, which apparently can sometimes cause warnings on mac. ac_save_CPPFLAGS=$CPPFLAGS CPPFLAGS="$LZ4_CFLAGS $CPPFLAGS" AC_CHECK_HEADERS(lz4/lz4.h, [], [AC_CHECK_HEADERS(lz4.h, [], [AC_MSG

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 10:35:21PM +0800, Julien Rouhaud wrote: > On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote: > > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote: > > The log-spam could be mitigated by logging it just once per connection > > the first time it is overridden >

Re: Proposal: Save user's original authenticated identity for logging

On Fri, 2021-03-19 at 17:21 +0900, Michael Paquier wrote: > On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote: > > Looking at 0001, I am not much a fan of relying on the position of the > > matching pattern in the log file. Instead of relying on the logging > > collector and one sing

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 10:27:51PM +0800, Julien Rouhaud wrote: > On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote: > > OK, that makes perfect sense. I think the best solution is to document > > that compute_query_id just controls the built-in computation of the > > query id, and that

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 optimiz

Re: support for MERGE

On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote: > On 3/19/21 10:44 AM, Alvaro Herrera wrote: > > On 2021-Mar-19, David Steele wrote: > > > > > Since it does not appear this is being worked on for PG14 perhaps we > > > should > > > close it in this CF and then reopen it when a patch

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 12:35 PM Justin Pryzby wrote: > I sent offlist a couple of times but notice that the latest patch is missing > this bit around AC_CHECK_HEADERS, which apparently can sometimes cause > warnings on mac. > > ac_save_CPPFLAGS=$CPPFLAGS > CPPFLAGS="$LZ4_CFLAGS $CPPFLAGS" > AC_CH

Failed assertion on standby while shutdown

Hi, haсkers! Recently, I was doing some experiments with primary/standby instances interaction. In certain conditions I’ve got and was able to reproduce crash on failed assertion. The scenario is the following: 1. start primary server 2. start standby server by pg_basebackup -P -R -X stream -

Re: cleanup temporary files after crash

On 3/19/21 5:26 PM, Tomas Vondra wrote: > On 3/19/21 5:23 PM, Tomas Vondra wrote: >> ... >> >> If I replace this with a wait loop in a plpgsql block, that works >> perfectly fine (no infinite loops). Tested both on x86_64 and rpi. >> > > For the record, here's the version with plpgsql block, which

Bringing some sanity to RestoreGUCState()

In the thread about valgrind leak detection [1], we noticed that RestoreGUCState(), which is intended to load the leader process's GUC settings into a parallel worker, was causing visible memory leaks by invoking InitializeOneGUCOption() on already-set-up GUCs. I noted that simply removing that cal

Re: Columns correlation and adaptive query optimization

Hi, In AddMultiColumnStatisticsForQual(), + /* Loop until we considered all vars */ + while (vars != NULL) ... + /* Contruct list of unique vars */ + foreach (cell, vars) What if some cell / node, gets into the else block: + else + { +

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 01:24:39PM -0400, Robert Haas wrote: > On Fri, Mar 19, 2021 at 12:35 PM Justin Pryzby wrote: > > I sent offlist a couple of times but notice that the latest patch is missing > > this bit around AC_CHECK_HEADERS, which apparently can sometimes cause > > warnings on mac. > >

Re: cleanup temporary files after crash

On Fri, Mar 19, 2021, at 2:27 PM, Tomas Vondra wrote: > I've pushed this version, with the plpgsql block. I've tested it on all > the machines I have here, hopefully it'll make buildfarm happy too. Thanks for taking care of this issue. > AFAICS I was mistaken about what the pump() functions do - i

Do we work with LLVM 12 on s390x?

The Red Hat folk are seeing a problem with that combination: https://bugzilla.redhat.com/show_bug.cgi?id=1940964 which boils down to > Build fails with this error: > ERROR: failed to JIT module: Added modules have incompatible data layouts: > E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 1:44 PM Justin Pryzby wrote: > Working with one of Andrey's patches on another thread, he reported offlist > getting this message, resolved by this patch. Do you see this warning during > ./configure ? The latest CI is of a single patch without the LZ4 stuff, so I > can't

Re: non-HOT update not looking at FSM for large tuple update

On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > > > + * The minimum space on a page for it to be considered "empty" regardless > > + * of fillfactor. We base this on MaxHeapTupleSize, minus a small amount > > + * of slack. We allow slack eq

Re: Proposal: Save user's original authenticated identity for logging

On Fri, 2021-03-19 at 16:54 +, Jacob Champion wrote: > One additional improvement I would suggest, now that the rotation logic > is simpler than it was in my original patch, is to rotate the logfile > regardless of whether the test is checking the logs or not. (Similarly, > we can manually rota

Re: non-HOT update not looking at FSM for large tuple update

On Fri, 19 Mar 2021 at 19:16, John Naylor wrote: > > On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent > wrote: > > > > This is slightly more verbose, but I think this clarifies the > > reasoning why we need this a bit better. Feel free to reject or adapt > > as needed. > > I like this in ge

Replication slot stats misgivings

Hi, I started to write this as a reply to https://postgr.es/m/20210318015105.dcfa4ceybdjubf2i%40alap3.anarazel.de but I think it doesn't really fit under that header anymore. On 2021-03-17 18:51:05 -0700, Andres Freund wrote: > It does make it easier for the shared memory stats patch, because if

Re: Do we work with LLVM 12 on s390x?

Hi, On 2021-03-19 14:03:21 -0400, Tom Lane wrote: > The Red Hat folk are seeing a problem with that combination: > > https://bugzilla.redhat.com/show_bug.cgi?id=1940964 > > which boils down to > > > Build fails with this error: > > ERROR: failed to JIT module: Added modules have incompatible d

Re: Do we work with LLVM 12 on s390x?

Andres Freund writes: > I think the error above comes from a "mismatch" between the clang used > to compile bitcode, and the LLVM version linked to. Normally we're > somewhat tolerant of differences between the two, but there was an ABI > change at some point, leading to that error. IIRC I hit th

Re: [PATCH] ProcessInterrupts_hook

David Steele writes: > On 1/19/21 1:42 AM, Craig Ringer wrote: >> My suggestion, which I'm happy to post in patch form if you think it's >> reasonable > Tom, Robert, and thoughts on the proposals in [1]? > https://www.postgresql.org/message-id/CAGRY4nyNfscmQiZBCNT7cBYnQxJLAAVCGz%2BGZAQDAco1Fbb0

Re: pglz compression performance, take two

> On Jan 21, 2021, at 6:48 PM, Justin Pryzby wrote: > > @cfbot: rebased > <0001-Reorganize-pglz-compression-code.patch> Review comments. First, I installed a build from master without this patch, created a test installation with lots of compressed text and array columns, upgraded the binar

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 18.03.21 09:28, Peter Eisentraut wrote: Which leads me to:  After retesting this now, with a new machine, the performance of the numeric implementation is brutal compared to the float implementation, for cases where we need numeric division, which is milliseconds, seconds, and epoch.  In the

Re: [PATCH] ProcessInterrupts_hook

On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote: > David Steele writes: > > On 1/19/21 1:42 AM, Craig Ringer wrote: > >> My suggestion, which I'm happy to post in patch form if you think it's > >> reasonable > > > Tom, Robert, and thoughts on the proposals in [1]? > > https://www.postgresql.org/m

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 10:11 AM Dilip Kumar wrote: > Also added a test case for vacuum full to recompress the data. I committed the core patch (0003) with a bit more editing. Let's see what the buildfarm thinks. -- Robert Haas EDB: http://www.enterprisedb.com

Re: [PATCH] ProcessInterrupts_hook

Robert Haas writes: > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote: >> I'm not very comfortable about the idea of having the postmaster set >> child processes' latches ... that doesn't sound terribly safe from the >> standpoint of not allowing the postmaster to mess with shared memory >> state

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call moved?   Is there some correctness issue?  If so, we should explain that (at least in the commit message, or as a separate patch). If you want I can split it out, or drop th

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Peter Eisentraut writes: > Well, I had an idea that I put to work. In most of these cases where we > need division, we divide an integer by a power of 10. That can be done > with numeric very quickly by just shifting the weight and scale around. > So I wrote a function that does that specific

Re: [HACKERS] Custom compression methods

Robert Haas writes: > I committed the core patch (0003) with a bit more editing. Let's see > what the buildfarm thinks. Since no animals will be using --with-lz4, I'd expect vast silence. regards, tom lane

Re: [HACKERS] Custom compression methods

I wrote: > Since no animals will be using --with-lz4, I'd expect vast silence. Nope ... crake's displeased with your assumption that it's OK to clutter dumps with COMPRESSION clauses. As am I: that is going to be utterly fatal for cross-version transportation of dumps. re

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: The main reason I didn't want to add more tracepoints than were strictly necessary is that Pg doesn't enable the systemtap semaphores feature, so right now we do a T_NAME(lock) evaluation each time we pass a tracepoint if --enable-dtrace is compiled in,

Re: pglz compression performance, take two

> On Jan 28, 2021, at 2:56 AM, Andrey Borodin wrote: > > > >> 22 янв. 2021 г., в 07:48, Justin Pryzby написал(а): >> >> @cfbot: rebased >> <0001-Reorganize-pglz-compression-code.patch> > > Thanks! > > I'm experimenting with TPC-C over PostgreSQL 13 on production-like cluster in > the cl

Re: [HACKERS] Custom compression methods

Hmm, if I use configure --with-lz4, I get this: checking whether to build with LZ4 support... yes checking for liblz4... no configure: error: Package requirements (liblz4) were not met: No package 'liblz4' found Consider adjusting the PKG_CONFIG_PATH envir

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 4:20 PM Tom Lane wrote: > Nope ... crake's displeased with your assumption that it's OK to > clutter dumps with COMPRESSION clauses. As am I: that is going to > be utterly fatal for cross-version transportation of dumps. Yes, and prion's got this concerning diff: Colum

Re: [HACKERS] Custom compression methods

On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: > I find this behavior confusing; I'd rather have configure error out if > it can't find the package support I requested, than continuing with a > set of configure options different from what I gave. +1

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Fri, Sep 11, 2020 at 5:11 PM James Coleman wrote: > > On Tue, Sep 8, 2020 at 4:37 PM Heikki Linnakangas wrote: > > > > On 08/09/2020 22:25, James Coleman wrote: > > > On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas > > > wrote: > > >> > > >> You could also apply the optimization for non-C

Re: Speeding up GIST index creation for tsvectors

On Fri, Mar 19, 2021 at 8:57 AM Amit Khandekar wrote: > > On Thu, 11 Mar 2021 at 04:25, John Naylor wrote: > > Okay, so it's hard-coded in various functions in contrib modules. In that > > case, let's just keep the existing coding for those. In fact, the comments > > that got removed by your patc

Re: [HACKERS] Custom compression methods

On 3/19/21 9:40 PM, Andres Freund wrote: > On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: >> I find this behavior confusing; I'd rather have configure error out if >> it can't find the package support I requested, than continuing with a >> set of configure options different from what I gave. >

Re: shared-memory based stats collector

Hi, On 2021-03-10 20:26:56 -0800, Andres Freund wrote: > > + shhashent = dshash_find_extended(pgStatSharedHash, &key, > > + > > create, nowait, create, &shfound); > > + if (shhashent) > > + { > > + if (create && !s

Re: [HACKERS] Custom compression methods

On 2021-03-19 22:19:49 +0100, Tomas Vondra wrote: > Yeah. And why does it even require pkg-config, unlike any other library > that I'm aware of? IMO it's fine to require pkg-config to simplify the configure code. Especially for new optional features. Adding multiple alternative ways to discover li

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 4:38 PM Robert Haas wrote: > Yes, and prion's got this concerning diff: > > Column | Type | Collation | Nullable | Default | Storage | > Compression | Stats target | Description > > +-+---+--+-+-+-+-

Re: [PATCH] Hooks at XactCommand level

Le 12/03/2021 à 06:55, Julien Rouhaud a écrit : > Hi, > > On Tue, Dec 08, 2020 at 11:15:12AM +0100, Gilles Darold wrote: >> Based on a PoC reported in a previous thread [1] I'd like to propose new >> hooks around transaction commands. The objective of this patch is to >> allow PostgreSQL extension

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 5:29 PM Andres Freund wrote: > On 2021-03-19 22:19:49 +0100, Tomas Vondra wrote: > > Yeah. And why does it even require pkg-config, unlike any other library > > that I'm aware of? > > IMO it's fine to require pkg-config to simplify the configure > code. Especially for new o

Re: Bringing some sanity to RestoreGUCState()

I wrote: > The argument for "sending too little" comes from the race condition > that's described in the function's comments: a variable that has > source PGC_S_DEFAULT (ie, has never moved off its compiled-in default) > in the leader could have just been updated in the postmaster, due to > re-read

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > > Regarding your point, that does look like clutter. We don't annotate > > the dump with a storage clause unless it's non-default, so probably we > > should do the same thing here. I think I gave Dilip bad advice here... > > Here's a patch for that. It's a lit

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > On Fri, Mar 19, 2021 at 10:11 AM Dilip Kumar wrote: > > Also added a test case for vacuum full to recompress the data. > > I committed the core patch (0003) with a bit more editing. Let's see > what the buildfarm thinks. I updated the coverage script to use

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 10:19:49PM +0100, Tomas Vondra wrote: > On 3/19/21 9:40 PM, Andres Freund wrote: > > On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: > >> I find this behavior confusing; I'd rather have configure error out if > >> it can't find the package support I requested, than conti

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > Here's one from me that tries to make the handling of the LZ4 stuff > more like what we already do for zlib, but I'm not sure if it's > correct, or if it's what everyone wants. This one seems to behave as expected (Debian 10, with and without liblz4-dev). --

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 6:22 PM Alvaro Herrera wrote: > Do you mean the column storage strategy, attstorage? I don't think > that's really related, because the difference there is not a GUC setting > but a compiled-in default for the type. In the case of compression, I'm > not sure it makes sens

  1   2   >