Re: Polyphase merge is obsolete

nk uint64 can be used (instead of int64). int64 is used elsewhere in this file, and I see now reason to do otherwise. Aside from s/14/15/ for the version as noted above, I've marked it Ready for Committer. -- John Naylor EDB: http://www.enterprisedb.com set -e ROWS=$1 function log { echo `dat

Re: [RFC] building postgres with meson

ems not to know to use CWD here. Anyway, this can be put off until the very end, since it's not run often. You've demonstrated how these targets would work, and that's good enough for now. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

I plan to push v25 early next week, unless there are further comments. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up text_position() for utf-8

| 1220 | 1220 | 1150 master | 385 | 2420 | 1980 0001 | 390 | 2180 | 1670 0002 | 389 | 1330 | 1100 0003 | 391 | 2100 | 1360 -- John Naylor EDB: http://www.enterprisedb.com v2-0002-Refactor-text_position_get_match_pos-to-use

Re: do only critical work during single-user vacuum?

. --min-xid-age > option and --min-mxid-age option of vacuumdb command would be good > examples. So I think this new command/facility might not necessarily > need to be specific to single-user mode. If we want to leave open the possibility to specify these parameters, a SQL-callable function s

Re: do only critical work during single-user vacuum?

On Tue, Dec 21, 2021 at 5:56 PM Peter Geoghegan wrote: > > On Tue, Dec 21, 2021 at 1:31 PM John Naylor > wrote: > > On second thought, we don't really need another number here. We could > > simply go by the existing failsafe parameter, and if the admin wants a > > di

Re: do only critical work during single-user vacuum?

things we can do in this regard, but something like the above could also be useful in normal operation. In fact, that "normal" could be just after we restarted after doing the bare-minimum in single-user mode, and want to continue freezing and keep things under control. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

um_failsafe_age/vacuum_multixact_failsafe_age in a session, including in single-user mode. Perhaps a new boolean called FAILSAFE_ONLY. If no table is specified, then when generating the list of tables, include only those with relfrozenxid/relminmxid greater than their failsafe thresholds. -- John Naylor EDB: http://www.enterprisedb.com

Re: Introducing PgVA aka PostgresVectorAcceleration using SIMD vector instructions starting with hex_encode

ating > point output …) which could be addressed later on. Float output has already been pretty well optimized. CRC checksums already have a hardware implementation on x86 and Arm. I don't know of any practical workload where generate_series() is too slow. Aggregation is an interesting case, but I'm not sure what the current bottlenecks are. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

On Fri, Dec 17, 2021 at 9:29 AM John Naylor wrote: > > I plan to push v25 early next week, unless there are further comments. Pushed, thanks everyone! -- John Naylor EDB: http://www.enterprisedb.com

Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

+ * during transaction commit, but it should handle most scenarios. And do we need additional tests? Maybe we don't, but it seems good to make sure. I haven't looked at 0007, and I have no opinion on which approach is better. -- John Naylor EDB: http://www.enterprisedb.com

Re: Parallel vacuum workers prevent the oldest xmin from advancing

let's wait for a day or so to see if anybody else has any ideas to > write a test for this case, otherwise, I'll check these once again and > push. I set this "committed" in the CF app. -- John Naylor EDB: http://www.enterprisedb.com

Re: Non-decimal integer literals

numeric literal at or near "1b" +LINE 1: SELECT 1b; + ^ We might consider some tests for ECPG since lack of coverage has been a problem. Also, I'm curious: how does the spec work as far as deciding the year of release, or feature-freezing of new items? -- John Naylor EDB: http://www.enterprisedb.com

do only critical work during single-user vacuum?

have a chance to get a handle on things. Thoughts? -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

is to export some symbols and add the counting function. That wouldn't materially affect the current patch for input verification, and would be separate, but it would be nice to get the symbol visibility right up front. I've set this to waiting on author while I experiment with that. -- Joh

Re: cutting down the TODO list thread

terribly helpful to someone trying to get up to speed on the issues that are still relevant. I don't see any more recent discussion, either. Thoughts? -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

[Peter again] > single-user mode should prompt the user about > what exact VACUUM command they ought to run to get things going. The current message is particularly bad in its vagueness because some users immediately reach for VACUUM FULL, which quite logically seems like the most complete thing to do. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

F8_3B_LEAD(*s) || - IS_UTF8_4B_LEAD(*s)) + if (!IS_HIGHBIT_SET(*s) || pg_utf_mblen(s) > 1) And I moved is_valid_ascii() to pg_wchar.h so it can be used elsewhere. I'm not sure there's a better place to put it. I tried using this for text_position(), for which

speed up text_position() for utf-8

/utf8.h -- John Naylor EDB: http://www.enterprisedb.com src/backend/utils/adt/varlena.c | 112 src/common/wchar.c | 90 ++-- src/include/mb/pg_wchar.h | 53 --- src/test/regress/regress.c

Re: cutting down the TODO list thread

On Wed, Dec 8, 2021 at 1:40 PM John Naylor wrote: > > It's been a while, but here are a few more suggested > removals/edits/additions to the TODO list. Any objections or new > information, let me know: > > - Auto-fill the free space map by scanning the buffer cache or by > c

Re: speed up text_position() for utf-8

920 > inline pg_utf_mblen() + ascii fast path | 382 | 470 | 918 I failed to mention that the above numbers are milliseconds, so smaller is better. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

i)) Note to self: I actually think this isn't needed anymore since I changed how the SSE code deals with remainder sequences at the end. -- John Naylor EDB: http://www.enterprisedb.com v19-rewrite-pg_verify_str-for-speed.patch Description: Binary data

Re: add 'noError' to euc_tw_and_big5.c

achment. > > That sounds right to me. Double-checking the area, I am not seeing > another portion of the code to fix. Agreed, will push. -- John Naylor EDB: http://www.enterprisedb.com

Re: add 'noError' to euc_tw_and_big5.c

achment. > > That sounds right to me. Double-checking the area, I am not seeing > another portion of the code to fix. Pushed, but I forgot to give you review credit, sorry about that. Thanks for taking a look! -- John Naylor EDB: http://www.enterprisedb.com

Re: postgresql.conf.sample missing units

On Mon, Jul 19, 2021 at 10:31 AM John Naylor wrote: > > On Mon, Jul 19, 2021 at 5:44 AM Pavel Luzanov wrote: > > > > Hello, > > > > I found that the start section of the postgresql.conf file is missing a > > description of two units: bytes (appeared

Re: speed up verifying UTF-8

94 |989 and for comparison, v14: chinese | mixed | ascii | mixed16 | mixed8 -+---+---+-+ 674 | 346 |78 | 309 |504 v17-0002: chinese | mixed | ascii | mixed16 | mixed8 -+---+---+-+ 516 | 324 |78 | 33

Re: O_DIRECT on macOS

2dbe8905.) It didn't show up in the archives, either. Neither did your follow-up 04cad8f7bc. -- John Naylor EDB: http://www.enterprisedb.com

Re: postgresql.conf.sample missing units

atch makes these changes to the postgresql.conf.sample file. Seems like an oversight. I'll commit this soon barring objections. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

be strictly greater-than, otherwise an invalid byte + * at the end might not get detected. + */ + while (len > sizeof(__m128i)) ...which should have more detail on this. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

_LEAD macros. pg_utf8_verifychar() is a public function usually called through pg_wchar_table[], so it needs to remain in any case. -- John Naylor EDB: http://www.enterprisedb.com

Re: truncating timestamps on arbitrary intervals

n't worth going through the patching process I'm not familiar with. Thanks for the pull request! I added tests and reworded the error message slightly to match current style, and pushed. -- John Naylor EDB: http://www.enterprisedb.com

Re: [POC] verifying UTF-8 using SIMD instructions

2); ... x = vsetq_lane_u8(x15, x, 14); x = vsetq_lane_u8(x16, x, 15); return x; Since you aligned the array, that might not have the problem alluded to above, and it looks nicer. -- John Naylor EDB: http://www.enterprisedb.com

Re: [POC] verifying UTF-8 using SIMD instructions

On Wed, Jul 21, 2021 at 8:08 PM Thomas Munro wrote: > > On Thu, Jul 22, 2021 at 6:16 AM John Naylor > One question is whether this "one size fits all" approach will be > extensible to wider SIMD. Sure, it'll just take a little more work and complexity. For one, 16-byte

Re: Use quick select instead of qsort to get median

this would add even more. Looking in the docs [2], we don't have a MEDIAN aggregate, but we do have percentile_disc(), and quick select might help there, but I haven't looked. [1] https://commitfest.postgresql.org/33/3038/ [2] https://www.postgresql.org/docs/14/functions-aggregate.html -- John Naylor EDB: http://www.enterprisedb.com

Re: truncating timestamps on arbitrary intervals

boundary is intentionally the earlier one: /* * Make sure the returned timestamp is at the start of the bin, even if * the origin is in the future. */ if (origin > timestamp && stride_usecs > 1) tm_delta -= stride_usecs; I wonder if we should just disallow negative in

Re: speed up verifying UTF-8

was too slow. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

Forgot the attachments... -- John Naylor EDB: http://www.enterprisedb.com v17-0001-Rewrite-pg_utf8_verifystr-for-speed.patch Description: Binary data v17-0004-Second-attempt-at-addressing-performance-regress.patch Description: Binary data v17-0002-Use-integer-chunk-for-fast-path-multibyte

Re: speed up verifying UTF-8

-+---+---+-+ 576 | 439 | 154 | 557 |915 -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

it down from v14. Any interest in testing on 64-bit Arm? -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/common/wchar.c b/src/common/wchar.c index 0636b8765b..177c607be6 100644 --- a/src/common/wchar.c +++ b/src/common/wchar.c @@ -13,8 +13,47 @@ #include "c.h" #include

Re: truncating timestamps on arbitrary intervals

January 4 of that year. In other words, the first Thursday of a year is in week 1 of that year." > Sorry for the verbose report and thanks for the nice function - I know it's not yet released, was just playing around with beta as I want to align CrateDB date_bin with Postgresql Thanks again for

Re: truncating timestamps on arbitrary intervals

de-step the issue, especially as we're in beta. Concretely, I propose to push the attached on master and v14. Since we're in beta 2 and this thread might not get much attention, I've CC'd the RMT. -- John Naylor EDB: http://www.enterprisedb.com 0001-Disallow-negative-strides-in-date_bin.patch Description: Binary data

Re: speed up verifying UTF-8

-- that would be a better reason to do it. [1] https://www.postgresql.org/message-id/2f95e70d-4623-87d4-9f24-ca534155f179%40iki.fi -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

- 142 |92 |59 | 141 |141 I'm pretty happy with the patch at this point. -- John Naylor EDB: http://www.enterprisedb.com From c82cbcf342f986396152a743a552626757b0a2b3 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Sun, 25 Jul 2021 20:41:41 -0400 Subject: [PATCH v20] Add a

Re: speed up verifying UTF-8

On Mon, Jul 26, 2021 at 7:55 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Just wondering, do you have the code in a GitHub/Gitlab branch? Sorry, I didn't see this earlier. No, I don't. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up verifying UTF-8

--+-+ 952 | 632 | 180 | 800 | 1333 A big-endian 64-bit platform just might shave enough cycles to beat v14 this way... or not. -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/common/wchar.c b/src/common/wchar.c index 0636b8765b..f48d79638c 100644 ---

Re: Unused function parameter in get_qual_from_partbound()

On Mon, Jul 12, 2021 at 8:46 AM John Naylor wrote: > > On Tue, Jun 8, 2021 at 10:50 PM Michael Paquier wrote: > > > > At first glance, this looked to me like breaking something just for > > sake of breaking it, but removing the rel argument could be helpful > >

Re: do only critical work during single-user vacuum?

(including > indexes) with an age above 500M on the weekends. There is already vaccumdb for that, and I think it's method of selecting tables is sound -- I'm not convinced that pushing table selection to the server command as "options" is an improvement. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

On Tue, Jan 11, 2022 at 9:20 PM Justin Pryzby wrote: > > On Tue, Jan 11, 2022 at 07:58:56PM -0500, John Naylor wrote: > > + // FIXME: also check reloption > > + // WIP: 95% is a starting point for discussion > > + if ((table_xid_age <

Re: do only critical work during single-user vacuum?

case, the admin would still need to add INDEX_CLEANUP = off for minimum downtime, and it should be really simple. - For the general case, we would now have the ability to vacuum a table, and possibly have no effect at all. That seems out of place with the other options. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

On Tue, Jan 11, 2022 at 8:57 PM Peter Geoghegan wrote: > On Tue, Jan 11, 2022 at 4:59 PM John Naylor > > For the PoC I wanted to try re-using existing keywords. I went with > > "VACUUM LIMIT" since LIMIT is already a keyword that cannot be used as > > a table n

Re: A qsort template

RhTiQdVttNuC4W-Shdc2a-AA%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAFBsxsG_c24CHKA3cWrOP1HynWGLOkLb8hyZfsD9db5g-ZPagA%40mail.gmail.com -- John Naylor EDB: http://www.enterprisedb.com

Re: Should we improve "PID XXXX is not a PostgreSQL server process" warning for pg_terminate_backend(<>)?

y. Also, v5 was a big enough change from v4 that I put Nathan as the first author. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

t haven't done so here. It can be executed in normal mode (although it's not expected to be), which makes testing easier and allows for a future possibility of not requiring shutdown at all, by e.g. terminating non-superuser connections. -- John Naylor EDB: http://www.enterprisedb.com src/backend/comma

Re: Non-decimal integer literals

. 0007: I've attached an addendum to restore the no-backtrack property. Will the underscore syntax need treatment in the input routines as well? -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/backend/parser/Makefile b/src/backend/parser/Makefile index 827bc4c189..5ddb9a92f0 1

Re: Consistently use "startup process"/"WAL sender" instead of "Startup process"/"WAL Sender" in comments and docs.

; is being used instead of "WAL > sender". Let's be consistent across the docs and code comments. FWIW, docs need to hold to a higher standard than code comments. -- John Naylor EDB: http://www.enterprisedb.com

Re: Consistently use "startup process"/"WAL sender" instead of "Startup process"/"WAL Sender" in comments and docs.

rs that are worth fixing in the comments. I've pushed the doc fixes, thanks for the patch! -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

On Tue, Feb 15, 2022 at 11:22 AM Peter Geoghegan wrote: > > On Mon, Feb 14, 2022 at 8:04 PM John Naylor > wrote: > > The failsafe mode does disable truncation as of v14: > > > > commit 60f1f09ff44308667ef6c72fbafd68235e55ae27 > > Author: Peter Geoghegan >

Re: do only critical work during single-user vacuum?

t; 4) oldest in-progress transaction id by xid / xmin, with name > 5) oldest database datfrozenxid, with database name [...] > Also, adding an SRF providing the above in a useful format would be great for > monitoring and for "remote debugging" of problems. I concur it s

Re: do only critical work during single-user vacuum?

ging the message and docs is trivial. > It seemed worth noting this in comments above > should_attempt_truncation(). Pushed a commit to do that just now. Thanks for that. -- John Naylor EDB: http://www.enterprisedb.com

Re: minor code correction in typecmds.c

On Wed, Feb 16, 2022 at 7:17 PM Amul Sul wrote: > > Hi, > > The attached patch replaces the hard-coded type alignment value with > the defined macro for the same. Pushed, thanks! -- John Naylor EDB: http://www.enterprisedb.com

use rotate macro in more places

1) | ((hashkey & 0x8000) ? 1 : 0); + hashkey = pg_rotate_left32(hashkey, 1); -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/backend/executor/execGrouping.c b/src/backend/executor/execGrouping.c index af6e9c42d8..ce8f6cd047 100644 --- a/src/backend/executor/execGrouping.c +

Re: use rotate macro in more places

022 at 11:28 PM Tom Lane wrote: > > Some comments now look a bit too obvious to keep around, but maybe > > they should be replaced with a "why", instead of a "what": > > Yeah. Maybe like "combine successive hashkeys by rotating"? Done that way. Push

Re: initdb / bootstrap design

division of labor between initdb and bootstrap" -- John Naylor EDB: http://www.enterprisedb.com

Re: Mark all GUC variable as PGDLLIMPORT

in favor of setting up the PGDLLIMPORT macro so that it can just be used unconditionally. That can work because in frontend code, we need no marking in either the defining or consuming files for a variable exported from these libraries; and frontend code has no need to access variables exported from the core backend, either. -- John Naylor EDB: http://www.enterprisedb.com

Re: some aspects of our qsort might not be ideal

Lb_Xn4-6f1ofsf2qduf24dDCVHbQidt7JPpdL_RiT1zBJ6A%40mail.gmail.com -- John Naylor EDB: http://www.enterprisedb.com

Re: some aspects of our qsort might not be ideal

s we attempt before we give up and partition/recurse. The author's implementation chooses 8 for this limit. The paper mentions this technique in section 5.2, but is not the origin of it. -- John Naylor EDB: http://www.enterprisedb.com

some aspects of our qsort might not be ideal

b.com/orlp/pdqsort -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

On Wed, Mar 16, 2022 at 4:48 AM Peter Geoghegan wrote: > > On Wed, Feb 16, 2022 at 12:43 AM John Naylor > wrote: > > I'll put some effort in finding any way that it might not be robust. > > After that, changing the message and docs is trivial. > > It would be great

Re: A qsort template

will have to wait for a bit of analysis and retesting. (My earlier tests were done in a separate module.) The rest in this series that I looked at closely were either refactoring or could use some minor tweaks so likely v16 material. -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

itialised value was created by a stack allocation ==1940791==at 0x74224E: tuplesort_putheaptuple (tuplesort.c:1800) -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote: > > On Thu, Mar 31, 2022 at 11:09 PM John Naylor > wrote: > > In a couple days I'm going to commit the v3 patch "accelerate tuple > > sorting for common types" as-is after giving it one more look, barring >

Re: A qsort template

clause. I'll go through the failures and see how much can be cleaned up as a preparatory refactoring. -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

d,alignment" ... -- John Naylor EDB: http://www.enterprisedb.com

Re: CLUSTER sort on abbreviated expressions is broken

On Sun, Apr 3, 2022 at 11:05 AM Thomas Munro wrote: > > Hi, > > Independently of a problem with a recent commit, it seems that > $SUBJECT in all releases (well, I only tested as far back as 11). I can confirm the problem on v10 as well. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

Id(). I'm not sure if multi-word commands should be quoted like this. - A first draft of documentation -- John Naylor EDB: http://www.enterprisedb.com doc/src/sgml/maintenance.sgml | 12 ++-- doc/src/sgml/ref/vacuum.sgml| 22 src/backend/access/transam/varsup.c | 4 +-

Re: A qsort template

till thinking 20 or so is about right. I've put a lot out here recently, so I'll take a break now and come back in a few weeks. (no running tally here because the conclusions haven't changed since last message) -- John Naylor EDB: http://www.enterprisedb.com NOTICE: [direct] size=8MB, order=r

Re: speed up text_position() for utf-8

ached). The others can be faster or slower. 0002 also simplifies things, so it has that going for it. I plan to commit that this week unless there are objections. -- John Naylor EDB: http://www.enterprisedb.com haswell xeon / gcc 8 master: Time: 608.047 ms Time: 2859.939 ms (00:02.860) Time: 2255

Re: do only critical work during single-user vacuum?

t as well), but introduce a softer "only > > vacuum/drop/truncate" limit a good bit before that. > > +1. Since there seems to be agreement on this, I can attempt a stab at it, but it'll be another week before I can do so. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

elminmxid); > + > > I think that instead of calling xid_age and mxid_age for each > relation, we can compute the thresholds for xid and mxid once, and > then compare them to relation's relfrozenxid and relminmxid. That sounds like a good idea if it's simple to implement, so I will

Re: do only critical work during single-user vacuum?

on that I'll talk about in a minute. The word "advice" sounds like people have a choice, rather than the system not accepting commands anymore. It would be much less painful if the system closed connections and forbade all but superusers to connect, but that sounds like a lot of work. (

Re: do only critical work during single-user vacuum?

ugh to do that. I'll pursue that as a follow-up. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

On Thu, Feb 3, 2022 at 4:58 PM Andres Freund wrote: > > Hi, > > On 2022-02-03 16:18:27 -0500, John Naylor wrote: > > I just checked some client case notes where they tried just that > > before getting outside help, and both SELECT and VACUUM FREEZE > > command

Re: do only critical work during single-user vacuum?

On Thu, Feb 3, 2022 at 1:42 PM Robert Haas wrote: > > On Thu, Feb 3, 2022 at 1:34 PM John Naylor > wrote: > > The word "advice" sounds like people have a choice, rather than the > > system not accepting commands anymore. It would be much less painful >

Re: Stats collector's idx_blks_hit value is highly misleading in practice

pgstat_count_buffer_(read|hit). That > happens in ReadBufferExtended, which just has no idea what page it's > dealing with. Not sure how to do that cleanly ... Is this a TODO candidate? What would be a succinct title for it? -- John Naylor EDB: http://www.enterprisedb.com

Re: Stats collector's idx_blks_hit value is highly misleading in practice

On Fri, Feb 4, 2022 at 11:19 AM Peter Geoghegan wrote: > > On Thu, Feb 3, 2022 at 7:08 PM John Naylor > wrote: > > Is this a TODO candidate? What would be a succinct title for it? > > I definitely think that it's worth working on. I suppose it follows > that it sh

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

72,450 > Here is the same pg_stat_database info for master: > blks_hit | 283,015,966,386 > tup_fetched | 237,052,965,901 That's impressive. -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

, and also attached an extra draft spreadsheet. I'll improve the tests and rerun later) -- John Naylor EDB: http://www.enterprisedb.com NOTICE: [traditional qsort] size=8MB, order=random, cmp=arg, test=0, time=0.144545 NOTICE: [traditional qsort] size=8MB, order=random, cmp=arg, test=1, tim

Re: A qsort template

stgresql.org/message-id/CA%2BhUKG%2BS5SMoG8Z2PHj0bsK70CxVLgqQR1orQJq6Cjgibu26vA%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAFBsxsEFGAJ9eBpQVb5a86BE93WER3497zn2OT5wbjm1HHcqgA%40mail.gmail.com (TODO: refine test) -- John Naylor EDB: http://www.enterprisedb.com NOTICE: [direct] size=8MB, order=

Re: do only critical work during single-user vacuum?

. -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

emory usage is always good. Not sure what you mean by the third case -- there are 2+ sort keys, but the first is authoritative from the datum, so the full comparison can skip the first key? -- John Naylor EDB: http://www.enterprisedb.com qsort-specialize-types-jcn1.ods Description: application/vnd.oas

Re: do only critical work during single-user vacuum?

to have a simple, easy to type, command - intended for single-user mode, but not limited to it (so it's easy to test) - to get out of single user mode as quickly as possible -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c index 283f

Re: Time to increase hash_mem_multiplier default?

up in the external sorting code. Also, if the "generation context" idea gets traction, that might be another reason to consider differentiating the mem settings. -- John Naylor EDB: http://www.enterprisedb.com

Re: speed up text_position() for utf-8

chine, but not as fast as 0001 and 0002 together. Looking at the assembly, pg_mblen is inlined into pg_mbstrlen_[with_len] and pg_mbcliplen, so the specialization for utf-8 in 0001 would be inlined in the other 3 as well. That's only a few bytes, so I think it's fine. -- John Naylor EDB: http://www.enterprisedb.com

Re: do only critical work during single-user vacuum?

a bit more natural than VACUUM LIMIT. Opinions? -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

On Tue, Jan 18, 2022 at 9:58 PM Peter Geoghegan wrote: > > On Tue, Jan 18, 2022 at 6:39 PM John Naylor > wrote: > > Editorializing the null position in queries is not very common in my > > experience. Not null is interesting since it'd be trivial to pass > > constant

Re: autovacuum prioritization

for the VM even if they have not reached the configured threshold. So a worker would check the wraparound queue, and if nothing's there grab something from the other queue. Maybe low-priority work would have a low cost limit. Probably the true best way to do schedule, at least at first, is what's the

Re: Mark all GUC variable as PGDLLIMPORT

ood? Should I try to do it earlier, > before we technically hit 8am? Should I do it the night before, last > thing before I go to bed on Thursday? Do you care whether your commit > or mine goes in first? For these two patches, I'd say a day or two after feature freeze is a reasonable goal. -- John Naylor EDB: http://www.enterprisedb.com

Re: A qsort template

kip the retest of column 1 in the tiebreak comparator. > Perhaps you'd just install a different comparetup function, eg > comparetup_index_btree_tail (which would sharing code), so no need to > multiply specialisations for that. If we need to add these cases to avoid regression, it ma

Re: A qsort template

es restore performance for those. More broadly than the regression, Thomas' is very often the fastest of all, at the cost of more binary size. David's is occasionally slower than v15 or v15 with revert, but much of that is a slight difference and some is probably noise. -- John Naylor

Re: A qsort template

Naylor EDB: http://www.enterprisedb.com From 74b934bc5ed8f6733c064c0ef832e1aa9949f216 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Wed, 6 Apr 2022 16:38:28 +0700 Subject: [PATCH v5] Raise qsort insertion sort threshold Our qsort algorithm is from NetBSD and is described in the 1993 paper

<    2   3   4   5   6   7   8   9   10   11   >