example, we expect 1.5% of the page could be line items, then:
>
> targetFreeSpace = MaxHeapTupleSize * 0.985
That makes sense, although the exact number seems precisely tailored to
your use case. 2% gives 164 bytes of slack and doesn't seem too large.
Updated patch attached.
--
John Naylor
EDB: h
to take your -50 idea and make it more general and safe, by
scaling the fudge factor based on fillfactor, such that if fillfactor is
less than 100, the requested freespace is a bit smaller than the max. It's
still a bit of a hack, though. I've attached a draft of this idea.
--
John Naylor
E
d make sure it looks sane in
page_inspect, but that's about it.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Feb 15, 2021 at 9:32 PM John Naylor
wrote:
>
> On Mon, Feb 15, 2021 at 9:18 AM Heikki Linnakangas
wrote:
> >
> > I'm guessing that's because the unaligned access in check_ascii() is
> > expensive on this platform.
> Some possible remedies:
>
tually completely broken if you tried to pass the special flags to
configure. I redesigned this part and it seems to work now.
--
John Naylor
EDB: http://www.enterprisedb.com
v4-SSE4-with-autoconf-support.patch
Description: Binary data
warnings in the magic
constants macros. That needs some polish.
I also attached a C file that visually demonstrates every step of the
algorithm following the example found in Table 9 in the paper. That
contains the skeleton coding I started with and got abandoned early, so it
might differ from the actual patch.
--
John Naylor
EDB: http://www.enterprisedb.com
v3-SSE4-with-autoconf-support.patch
Description: Binary data
test-utf8.c
Description: Binary data
N opclass multi-minmax currently
in development. It's designed to address that exact situation, and more
review would be welcome:
https://commitfest.postgresql.org/32/2523/
--
John Naylor
EDB: http://www.enterprisedb.com
dded
by the noError argument patch)
2. Add SSE4 validator -- it turns out the demo I referred to earlier
doesn't match the algorithm in the paper. I plan to only copy the lookup
tables from simdjson verbatim, but the code will basically be written from
scratch, using simdjson as a hint.
3. Adjus
On Tue, Feb 9, 2021 at 4:22 PM Heikki Linnakangas wrote:
>
> On 09/02/2021 22:08, John Naylor wrote:
> > Maybe there's a smarter way to check for zeros in C. Or maybe be more
> > careful about cache -- running memchr() on the whole input first might
> > not be the be
re updated 8-12 years ago, but that would still be
something to check, in addition to more configure checks.
[1] https://github.com/lemire/fastvalidate-utf-8/tree/master/include
--
John Naylor
EDB: http://www.enterprisedb.com
utf-sse42-demo.patch
Description: Binary data
27;s a smarter way to check for zeros in C. Or maybe be more
careful about cache -- running memchr() on the whole input first might not
be the best thing to do.
--
John Naylor
EDB: http://www.enterprisedb.com
gt; shouldn't do that either. For existing minmax indexes that's useless
> (the opclass seems to be working, otherwise the index would be dropped).
> But even for new indexes I'm not sure it's the right thing, so I don't
> plan to change this.
Okay.
--
John Naylor
EDB: http://www.enterprisedb.com
On Sun, Feb 7, 2021 at 2:13 PM Heikki Linnakangas wrote:
>
> On 02/02/2021 23:42, John Naylor wrote:
> >
> > In copyfromparse.c, this is now out of date:
> >
> > * Read the next input line and stash it in line_buf, with conversion
to
> > * server encoding.
bytes
> aligned. Use memcpy to fetch the next 8-byte chunk to fix.
Will do.
[1] https://github.com/lemire/fastvalidate-utf-8/tree/master/include
[2]
https://lemire.me/blog/2018/10/19/validating-utf-8-bytes-using-only-0-45-cycles-per-byte-avx-edition/
--
John Naylor
EDB: http://www.enterprisedb.com
noticeably slower on pure ascii, but still several times faster than
before, so the conclusions haven't changed any. I'll run full measurements
later this week, but I'll share the patch now for review.
[1]
https://www.postgresql.org/message-id/11d39e63-b80a-5f8d-8043-fff04201f...@i
On Mon, Feb 1, 2021 at 2:01 PM Heikki Linnakangas wrote:
>
> On 01/02/2021 19:32, John Naylor wrote:
> > It makes sense to start with the ascii subset of UTF-8 for a couple
> > reasons. First, ascii is very widespread in database content,
> > particularly in bulk loa
d but weren't.
The other case is 'voilà', found in rules.sgml. The case for italics here
is stronger, but looking at that file, I actually think a more
generic-sounding phrase here would be preferable.
Other opinions?
--
John Naylor
EDB: http://www.enterprisedb.com
n multibyte delimiters in the wild, so it's not as outlandish as it
seems. The fix is simple enough, so +1.
--
John Naylor
EDB: http://www.enterprisedb.com
ffer */
Lastly, it looks like pg_do_encoding_conversion_buf() ended up in 0003
accidentally?
--
John Naylor
EDB: http://www.enterprisedb.com
gresql.org/message-id/06d45421-61b8-86dd-e765-f1ce527a5...@iki.fi
--
John Naylor
EDB: http://www.enterprisedb.com
diff --git a/src/common/wchar.c b/src/common/wchar.c
index 6e7d731e02..12b3a5e1a2 100644
--- a/src/common/wchar.c
+++ b/src/common/wchar.c
@@ -13,6 +13,10 @@
#include "c.h"
On Tue, Jan 26, 2021 at 6:59 PM Tomas Vondra
wrote:
>
>
>
> On 1/26/21 7:52 PM, John Naylor wrote:
> > On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > wrote:
> > > Hmm. I think Alvaro also
unconsumed bytes available in raw_buf */
#define RAW_BUF_BYTES(cstate) ((cstate)->raw_buf_len -
(cstate)->raw_buf_index)
It might make sense to create a CONVERSION_BUF_BYTES equivalent since the
patch calculates cstate->conversion_buf_len - cstate->conversion_buf_index
in a couple plac
#x27;) loop
+for byte3 in hex('a1')..hex('fe') loop
+ return next b(byte1, byte2, byte3);
+end loop;
+ end loop;
Not sure if it matters , but thought I'd mention it anyway.
--
John Naylor
EDB: http://www.enterprisedb.com
drive_conversion.c
Description: Binary data
On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
wrote:
>
>
> On 1/23/21 12:27 AM, John Naylor wrote:
> > Still, it would be great if multi-minmax can be a drop in replacement. I
> > know there was a sticking point of a distance function not being
> > available on all
for page header and tuple
header at least. As the comment before says, the filter will eventually not
be compressible. I remember we can't be exact here, with the possibility of
multiple columns, but we can leave a little slack space.
--
John Naylor
EDB: http://www.enterprisedb.com
rom generate_series(
'2020-01-01 0:00'::timestamptz,
'2020-02-01 23:59'::timestamptz,
'1 second'::interval) x;
-- mono-10-asc
truncate table iot;
insert into iot (num, create_dt)
select random(), '2020-01-01 0:00'::timestamptz + (x % 10 || '
seconds')::interval
from generate_series(1,5*365*24*60*60) x;
--
John Naylor
EDB: http://www.enterprisedb.com
mp_eq
There's no one place that's pathological enough to explain the 4x slowness
over traditional BRIN and nearly 3x slowness over btree when using a large
number of unique values per range, so making progress here would have to
involve a more holistic approach.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Nov 23, 2020 at 1:44 PM John Naylor
wrote:
>
> On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> > - After reading the discussion a few times, I'm not so sure anymore
> > whether making this a cousin of date_trun
On Thu, Jan 14, 2021 at 1:55 AM Michael Paquier wrote:
>
> On Wed, Jan 13, 2021 at 11:28:55PM +0900, Fujii Masao wrote:
> > On Wed, Jan 13, 2021 at 10:51 PM John Naylor <
john.nay...@enterprisedb.com> wrote:
> >> It is strange, now that I think about it. My thinki
be consistent within a single message. Maybe the parameter should be
spelled exactly as is, with underscores? I'll take a broader look and send
an updated patch.
--
John Naylor
EDB: http://www.enterprisedb.com
Hi,
The parameter replication_timeout was retired in commit 6f60fdd701 back in
2012, but some comments and error messages seem to refer to that old
setting instead of wal_sender_timeout or wal_receiver_timeout. The attached
patch replaces the old language with more specific references.
--
John
magine something algorithmic is
involved. Is it worth digging further to see if some code path is taking
more time than we would expect?
--
John Naylor
EDB: http://www.enterprisedb.com
re-create it with
> the new function signature afterwards. A note in the release notes and a
> check in pg_upgrade, with instructions to drop and recreate the
> conversion, are probably enough.
>
That was my thought as well.
--
John Naylor
EDB: http://www.enterprisedb.com
out upgrade compatibility. Is that
because user-defined conversions would no longer have the right signature?
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Dec 10, 2020 at 3:29 PM John Naylor
wrote:
>
> *Views and Rules
> *SQL Commands
Hearing no objections, the items mentioned have been moved over.
--
John Naylor
EDB: http://www.enterprisedb.com
to work in multiple-argument aggregate calls
Tom suggested this in 2006 for the sake of orthogonality. Given the amount
of time passed, it seems not very important.
- Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
Some use cases mentioned, but nearly all have some kind of worka
On Tue, Dec 8, 2020 at 5:45 AM Michael Paquier wrote:
>
> On Mon, Dec 07, 2020 at 03:24:56PM -0400, John Naylor wrote:
> > We've had get_canonical_class() for a while as a backend-only function.
> > There is some ad-hoc code elsewhere that implements the same logic in a
&
We've had get_canonical_class() for a while as a backend-only function.
There is some ad-hoc code elsewhere that implements the same logic in a
couple places, so it makes sense for all sites to use this function
instead, as in the attached.
--
John Naylor
EnterpriseDB:
On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 2020-06-30 06:34, John Naylor wrote:
> > In v9, I've simplified the patch somewhat to make it easier for future
> > work to build on.
> >
> > - When truncati
With the exception of "Fix /contrib/btree_gist's implementation of inet
indexing", all items above have been either moved over, or removed if they
were done already by PG13.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
his at any point since then.
>
> Pushed.
>
Documenting or improving IS OF was a TODO, so I've removed that entry.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Nov 18, 2020 at 3:05 PM Tom Lane wrote:
> John Naylor writes:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections, let me
> > know. I'll make the m
On Wed, Nov 18, 2020 at 2:42 PM Bruce Momjian wrote:
> On Wed, Nov 18, 2020 at 02:26:46PM -0400, John Naylor wrote:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections,
discussion thread.
- More sensible support for Unicode combining characters, normal forms
We have normalization as of PG13, so I propose to mark this Done rather
than move it.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Nov 11, 2020 at 4:45 PM John Naylor
wrote:
> Here is the next section on data types, proposed to be moved to the "not
> worth doing" page. As before, if there are any objections, do speak up.
> I'll make the move in a few days.
>
Hearing no objection,
ay
Unclear path forward
- better handling of XPath data types
- Improve handling of PIs and DTDs in xmlconcat()
Zero interest
- Restructure XML and /contrib/xml2 functionality
As discussed in the thread, it's an unrealistically large project
--
John Naylor
EnterpriseDB: http://www.en
On Tue, Nov 10, 2020 at 7:08 PM Bruce Momjian wrote:
> On Tue, Nov 3, 2020 at 02:06:13PM -0400, John Naylor wrote:
> > I was thinking of not having the next updates during commitfest, but it
> could
> > also be argued this is a type of review, and the things here will be
&
e work down the line.
>
> The attached patch cleans this up to make them all look like the first
> style.
>
+1 for standardizing in this area. It's worth noting that Bison 3.0
introduced %empty for this situation, which is self-documenting. Until we
get there, this is a good step
gt; but the whole index row is too large). But it's probably better to do at
> least something, and maybe improve that later with some whole-row check.
A whole-row check would be nice, but I don't know how hard that would be.
As a Devil's advocate proposal, how awful would it be to not allow
multicolumn brin-bloom indexes?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ld have it
check only odd numbers. That's a common feature of sieves, but also makes
the code a bit harder to understand if you haven't seen it before.
Also to fill in something I left for later, the reference for this
/* upper bound of number of primes below limit */
/* WIP: reference for t
On Mon, Nov 9, 2020 at 2:12 AM Fujii Masao
wrote:
> Pushed. Thanks!
>
Thank you!
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
There is a latent bug in the way code pairs for recomposition are sorted
due to a copy-pasto on my part. Makes no difference now, but it could in
the future. While looking, it seems pg_bswap.h should actually be
backend-only. Both fixed in the attached.
--
John Naylor
EnterpriseDB: http
On Thu, Nov 5, 2020 at 2:20 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-05 12:59, John Naylor wrote:
> > I think we're talking past eachother. Here's a concrete example:
> >
> > #define BKI_ROWTYPE_OID(oid,oidmacro)
> > #
On Thu, Nov 5, 2020 at 4:24 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-27 13:12, John Naylor wrote:
> > There's nothing wrong; it's just a minor point of consistency. For the
> > first part, I mean defined symbols in this file
rejected, in a way. Ultimately, it comes down to
"when time permits".
[1]
https://www.postgresql.org/message-id/flat/CAFBsxsGsBZsG%3DcLM0Op5HFb2Ks6SzJrOc_eRO_jcKSNuqFRKnQ%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAFBsxsEmg=kqrekxrlygy0ujcfyck4vgxzkalrwh_olfj8o...@mail.gmail.com
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s, so I
> move it to "Waiting on author".
>
> As I understand, the patch he posted is fine -- it only crashes when he
> tried a change I suggested.
That's my recollection as well.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
This is the other doc fix as suggested in
https://www.postgresql.org/message-id/20201027220555.GS4951%40momjian.us
There is already a compatibility section, so put there.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v1-doc-fix-revoke-role.patch
On Fri, Oct 30, 2020 at 12:48 PM Tom Lane wrote:
> John Naylor writes:
> > Okay, along those lines here's a patch using "this view" in a new
> paragraph
> > for simplicity.
>
> Basically OK with me, but ...
>
>
> It seems fairly weird to use a n
On Fri, Oct 30, 2020 at 12:07 PM Tom Lane wrote:
> John Naylor writes:
> > On Thu, Oct 29, 2020 at 11:51 PM Fujii Masao <
> masao.fu...@oss.nttdata.com>
> > wrote:
> >> Also I think this note should be in the different paragraph from the
> >> paragra
On Thu, Oct 29, 2020 at 11:51 PM Fujii Masao
wrote:
>
>
> On 2020/10/29 21:54, John Naylor wrote:
>
> > The pg_settings does not display
> > customized options
> > that have been set before the relevant extension module has been
> loaded.
>
> I
oing", but I'm open to better
ideas. Once that's agreed upon, I'll make a new page and migrate the items
over, minus the two that were mentioned upthread.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Oct 28, 2020 at 11:38 PM Fujii Masao
wrote:
>
>
> On 2020/10/29 3:45, John Naylor wrote:
> > On Wed, Oct 28, 2020 at 2:15 PM John Naylor <
> john.nay...@enterprisedb.com <mailto:john.nay...@enterprisedb.com>> wrote:
> >
> > Starting separat
> */
> #define CASHOID MONEYOID
> #define LSNOID PG_LSNOID
>
> #endif
>
Here is a quick patch implementing this much.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
forbid-custom-pg-type-symbols.patch
Description: Binary data
On Wed, Oct 28, 2020 at 3:24 PM Tom Lane wrote:
> and then the negotiation here is only about whether to make this list
> longer. We don't need to complicate genbki.pl with a new facility.
>
Agreed, and reformat_dat_files.pl must also know about these special
attributes.
-
On Wed, Oct 28, 2020 at 2:15 PM John Naylor
wrote:
> Starting separate threads to keep from cluttering the TODO list thread.
>
> Here's a patch for the subject, as mentioned in
> https://www.postgresql.org/message-id/20201027220555.GS4951%40momjian.us
>
I just realized I i
Starting separate threads to keep from cluttering the TODO list thread.
Here's a patch for the subject, as mentioned in
https://www.postgresql.org/message-id/20201027220555.GS4951%40momjian.us
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d
dler case is the
standard macros don't already exist for these pg_type entries. The handmade
macro idea could be used for all eight just as easily as for one.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
I wrote:
> Ok, here is a patch to fix that, and also throw an error if pg_proc.dat
> has an explicitly defined symbol.
>
It occurred to me I neglected to explain the error with a comment, which
I've added in v2.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
technical detail on the topic but if doing that, let's not
> mark them as that inline -- create a separate page with those items on
> it.
>
How about a section on the same page at the bottom, near "features we don't
want"?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Oct 27, 2020 at 6:05 PM Bruce Momjian wrote:
> On Tue, Oct 27, 2020 at 04:54:24PM -0400, John Naylor wrote:
> >
> >
> > On Tue, Oct 27, 2020 at 3:52 PM Bruce Momjian wrote:
> >
> >
> > Do any of these limitations need to be documented befor
On Tue, Oct 27, 2020 at 9:51 AM Tom Lane wrote:
> John Naylor writes:
> > I noticed that the table AM abstraction introduced the symbol
> > HEAP_TABLE_AM_HANDLER_OID, although we already have a convention for
> > defining symbols automatically for builtin functions, wh
E (I haven't looked further into
this)
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Oct 27, 2020 at 4:00 PM Thomas Munro wrote:
> On Wed, Oct 28, 2020 at 8:36 AM Andres Freund wrote:
> > On 2020-10-27 15:24:35 -0400, John Naylor wrote:
> > > - Allow WAL replay of CREATE TABLESPACE to work when the directory
> > > structure on the recovery com
nd old
- Change walsender so that it applies per-role settings
Old and possibly obsolete
--
[1]
https://www.postgresql.org/message-id/CAFBsxsHbqMzDoGB3eAGmpcpB%2B7uae%2BLLi_G%2Bo8HMEECM9CbQcQ%40mail.gmail.com
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
exist, as well as prevent such
symbols from being emitted into pg_proc_d.h. But then again there is
no guarantee the standard symbol is not being used elsewhere. Thoughts?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Oct 27, 2020 at 7:43 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-24 15:23, John Naylor wrote:
> > Style: In genbki.h, "extern int no_such_variable" is now out of place.
> > Also, the old comments like "The macro de
ace.
Also, the old comments like "The macro definitions are just to keep the C
compiler from spitting up." are now redundant in their new setting.
The rest looks good to me. unused_oids (once fixed), duplicate_oids, and
renumber_oids.pl seem to work fine.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Oct 22, 2020 at 10:11 PM Michael Paquier
wrote:
> On Thu, Oct 22, 2020 at 05:50:52AM -0400, John Naylor wrote:
> > Looks good to me.
>
> Thanks. Committed, then. Great work!
>
Thank you!
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
el free of course.
>
Looks good to me.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Oct 20, 2020 at 3:22 AM Michael Paquier wrote:
> On Mon, Oct 19, 2020 at 10:34:33AM -0400, John Naylor wrote:
> > I don't see any difference on gcc/Linux in those two files, nor in
> > unicode_norm_shlib.o -- I do see a difference in unicode_norm_srv.o as
> > ex
.gitattributes sounds fine to me. I simplified things a bit as the
> attached, getting rid of the last comma while on it. Does that look
> fine to you?
>
This is cleaner, so I'm good with this.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Oct 19, 2020 at 10:38 AM Tom Lane wrote:
> John Naylor writes:
> > On Mon, Oct 19, 2020 at 2:16 AM Peter Eisentraut <
> > peter.eisentr...@2ndquadrant.com> wrote:
> >> Could you adjust the generation script so that the resulting header file
> >>
On Fri, Oct 16, 2020 at 2:08 PM Daniel Verite
wrote:
> John Naylor wrote:
>
> > I'd be curious how it compares to ICU now
>
> I've made another run of the test in [1] with your v2 patches
> from this thread against icu_ext built with ICU-67.1.
> The resu
b.o -- I do see a difference in unicode_norm_srv.o as
expected. Could it depend on the compiler?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ing paren, so I don't see why it would
fire in this case. Is the manual backwards?
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ered, making it easier to keep the current
implementation in the front end, and hopefully getting even better
performance in the backend.
[1]
https://www.postgresql.org/message-id/2c5e8df9-43b8-41fa-88e6-286e8634f00a%40manitou-mail.org
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
x, 6117, on
pg_subscription_rel using btree(srrelid oid_ops, srsubid oid_ops));
#define SubscriptionRelSrrelidSrsubidIndexId 6117
to something like
DECLARE_UNIQUE_INDEX(btree(srrelid oid_ops, srsubid oid_ops), 6117,
SubscriptionRelSrrelidSrsubidIndexId));
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
" suggested upthread, but
> I'm not particularly volunteering to do it, either.
>
I'll start a separate thread for this. Working on one or a small number of
sections at a time should be manageable.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
y grepping for "left for future work" or
"for another day". I've gotten patch ideas (and more than one committed)
from these. If I were asked, that's where I'd point aspiring developers.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Oct 8, 2020 at 8:29 AM Michael Paquier wrote:
> On Thu, Oct 08, 2020 at 04:52:18AM -0400, John Naylor wrote:
> > Looks fine overall, but one minor nit: I'm curious why you made a
> separate
> > section in the pgindent exclusions. The style in that file seems to b
xclusions. The style in that file seems to be one
comment per category.
--
John Naylor
>
>
> On Sun, Oct 4, 2020 at 4:20 PM Tom Lane wrote:
> > I didn't try very hard to trace the commit history, but I did note that
> > almost all of the removed #includes dated to 1996 or so. I'm surprised
> > they survived Bruce's occasional attempts at removing unused #includes;
> > maybe his scr
On Sat, Oct 3, 2020 at 9:27 AM Craig Ringer
wrote:
> So a big +1 from me for the idea. Especially if we ensure psql recognises
when the relation 'oid' attribute has a declared PK and includes it in the
column list.
Oid has been in the normal column list since v12 when it stopped being a
system co
ric, too.
> I have no immediate suggestions on that score.
I've named it DeescapeQuotedString to see how that looks.
> In short: maybe instead of what you have here, leave GUC_scanstr()
> alone except for a possible rename; make bootscanner.l use that;
> and drop the now-unused
replace scanstr(), but with a different order of if-statements to
make the diff smaller. Since we have control over what goes in the BKI
file, we can use single-quoted escape strings there, allowing removal
of special case code for double quotes.
--
John Naylorhttps://www
OR: index row size 9056 exceeds maximum 8152 for index "x_a_b_c_idx"
Hmm, okay. As for which comes first, insert or index creation, I'm
baffled, too. I also would expect the example above would take up a
bit over 6000 bytes, but not 9000.
--
John Naylorhttps://www.2ndQu
On Thu, Sep 24, 2020 at 7:50 PM Tomas Vondra
wrote:
>
> On Thu, Sep 24, 2020 at 05:18:03PM -0400, John Naylor wrote:
> >Hmm, how ugly would it be to change the default range size depending
> >on the opclass?
> >
>
> Not sure. What would happen for multi-colu
On Mon, Sep 21, 2020 at 3:56 PM Tomas Vondra
wrote:
>
> On Mon, Sep 21, 2020 at 01:42:34PM -0400, John Naylor wrote:
> >While playing around with the numbers I had an epiphany: At the
> >defaults, the filter already takes up ~4.3kB, over half the page.
> >There is no ro
sitive_rate",
+ "desired false-positive rate for the bloom filters",
+ BLOOM_DEFAULT_FALSE_POSITIVE_RATE,
+ 0.001, 1.0, offsetof(BloomOptions, falsePositiveRate));
When I set fp to 1.0, the reloption code is okay with that, but then
later the assertion gets triggered.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
tra cycles would
have been noticeable here, but it can't hurt to have that guarantee.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
901 - 1000 of 1368 matches
Mail list logo
