hat WAL-logged changes in the FSM
fork are actually not recoverable from backup, regardless of the type
of contents, we should still keep track of the changes in the FSM fork
and include the fork in our backups or only exclude those FSM updates
that we know are safe to ignore.
Kind regards,
Matthias van de Meent
Neon, Inc.
s not force long down
> times
I agree that we should improve our upgrade process (and we had a great
discussion on the topic at the PGCon Unconference last week), but in
my view that's not relevant to this discussion.
Kind regards,
Matthias van de Meent
Neon, Inc.
performance benefits for older kernels, benefits which we
would get if we were to implement threading.
I'm not on board with a policy of us twiddling thumbs and waiting for
the OS to fix our architectural performance issues. Sure, the kernel
could optimize for our usage pattern, but I think that's n
On Thu, 8 Jun 2023 at 14:44, Hannu Krosing wrote:
>
> On Thu, Jun 8, 2023 at 2:15 PM Matthias van de Meent
> wrote:
> >
> > On Thu, 8 Jun 2023 at 11:54, Hannu Krosing wrote:
> > >
> > > This part was touched in the "AMA with a Linux Kernale Hacker&qu
ed address space, it'd be easier to do any cleanup necessary for
dynamically increasing/decreasing its size.
Same with parallel workers - if we have a shared address space, the
workers can pass any sized objects around without being required to
move the tuples through DSM and waiting for the leader process to
empty that buffer when it gets full.
Sure, most of that is probably possible with DSM as well, it's just
that I see a lot more issues that you need to take care of when you
don't have a shared address space (such as the pointer translation we
do in dsa_get_address).
Kind regards,
Matthias van de Meent
Neon, Inc.
On Tue, 23 May 2023 at 18:34, Robert Haas wrote:
>
> On Thu, May 18, 2023 at 8:06 AM Matthias van de Meent
> wrote:
> > This enum still has many options to go before it exceeds the maximum
> > of the uint8 va_tag field. Therefore, I don't think we have no disk
> >
e. But
this is data we store in the original tuple, and moving that around is
relatively expensive. Reducing the aligned size of the toast pointer
can help reduce the size of the heap tuple, thus increasing the
efficiency of the primary data table.
Kind regards,
Matthias van de Meent
Neon, Inc.
fra is built around 4 uint32 fields in the
toast pointer; but with this change in place we can devise a new toast
pointer that uses varint encoding on the length-indicating fields to
reduce the footprint of 18B to an expected 14 bytes.
Kind regards,
Matthias van de Meent
Neon, Inc.
On Thu, 18 May 2023 at 18:22, Heikki Linnakangas wrote:
>
> On 18/05/2023 17:59, Matthias van de Meent wrote:
> Perhaps we should introduce a few generic inline functions to do varint
> encoding. That could be useful in many places, while this scheme is very
> tailored for XLogRe
s didn't exceed those limits.
This change is immediately user-visible through a change in behaviour
of `pg_logical_emit_message(true, repeat('_', 2^30 - 10), repeat('_',
2^30 - 10))`, and extensions that implement their own rmgrs could also
see a change in behavior from this change.
Kind regards,
Matthias van de Meent
Neon, Inc.
lent to
`--locale=C` it now also overrides `--locale-provider=libc`, resulting
in undocumented behaviour.
Kind regards,
Matthias van de Meent
Neon, Inc.
[0]
https://www.postgresql.org/message-id/CAEze2WiZFQyyb-DcKwayUmE4rY42Bo6kuK9nBjvqRHYxUYJ-DA%40mail.gmail.com
er than this one.
Kind regards,
Matthias van de Meent
Neon, Inc.
[0] https://wiki.postgresql.org/wiki/Updating_the_WAL_infrastructure
[1]
https://www.postgresql.org/message-id/flat/CAEze2Wjd3jY_UhhOGdGGnC6NO%3D%2BNmtNOmd%3DJaYv-v-nwBAiXXA%40mail.gmail.com#17a51d83923f4390d8f407d0d6c5da07
nyway (see
VARSIZE_EXTERNAL(ptr)). By not using the varatt_external struct
currently in use, we could be able to get down to <18B toast pointers
as well, though I'd consider that unlikely.
Kind regards,
Matthias van de Meent
Neon, Inc.
7;t think we have no disk
representations left, nor do I think we'll need to add another option
to the ToastCompressionId enum.
As an example, we can add another VARTAG option for dictionary-enabled
external toast; like what the pluggable toast patch worked on. I think
we can salvage some ideas from that patch, even if the main idea got
stuck.
Kind regards,
Matthias van de Meent
Neon Inc.
set to "UTF8".
The default text search configuration will be set to "english".
Notably; if initdb chooses the C locale from --no-locale, it uses
SQL_ASCII through libc, but when the C locale is specified through
--locale=C, it somehow defaults to the ICU locale en-US and uses UTF8
as encoding.
In my view that's very unexpected behaviour.
Kind regards,
Matthias van de Meent
Neon (neon.tech)
On Tue, 16 May 2023 at 14:27, Robert Haas wrote:
>
> On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> wrote:
> > Agreed; and that's why I'm not against removing the specific wording
> > of the item. This may not have been clearly described in my previous
>
On Mon, 15 May 2023 at 20:51, Robert Haas wrote:
>
> On Mon, May 15, 2023 at 2:05 PM Matthias van de Meent
> wrote:
> > > Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE,
> > > and CLUSTER
> > > -> There are external too
opg, pg_qualstats and some manual
glue to get suggested indexes in the current database - but none of
these are available in the main distribution.
I'm not asking this to be part of the main PostgreSQL binary, but I
don't think that the idea of 'automated suggestions' should be moved
to
t store enough info about the compression used to
decompress the datum, which implies it needs to store the compression
algorithm used, and a reference to the compression dictionary (if
any). I think the idea about introducing a new toast pointer type (in
the custom toast patch) wasn't bad per se, and that change would allow
us to carry more or different info in the header.
Kind regards,
Matthias van de Meent
ffers in the range
are new, this can result in no buffers being registered in the last
iteration of the main loop (if the number of non-new buffers in the
range is 0 (mod 32)).
A change like attached should fix the issue; or alternatively we could
force log the last (new) buffer when we detect this edge case.
Kind regards,
Matthias van de Meent
7882549d3b6ca83e83eda88d46f6f29afda0ae03.diff
Description: Binary data
I think it's being worked on over there.
Kind regards,
Matthias van de Meent
[0] https://www.postgresql.org/message-id/flat/20230228190643.1e368315%40karst
[1]
https://www.postgresql.org/message-id/flat/3013398b-316c-638f-2a73-3783e8e2ef02%40enterprisedb.com#ceb9e14383122ade8b949b7479c6f7e2
ication
stream failures.
Kind regards,
Matthias van de Meent
hat my computer doesn't have...
> So, I was thinking about something like the attached tweaking this
> point, the error details a bit, applying an indentation and writing a
> commit message... Matthias?
>
That looks fine to me. Thanks for picking this up and fixing the issue.
Kind regards,
Matthias van de Meent
ld crash postgres
because commit xlog insertion happens in a critical section. Having a
pre-assembled record would greatly improve the ergonomics in that path
and reduce the length of the critical path.
I think it was something along the lines of the attached; 0001
contains separated Commit/Ab
On Wed, 29 Mar 2023 at 14:12, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > BufmgrCommit does exactly nothing; it is an empty function and has
> > been since commit 33960006 in late 2008 when it stopped calling
> > smgrcommit().
> > All two usages of the fu
().
All two usages of the function (in our code base) seem to be in
xact.c. Are we maintaining it for potential future use, or can the
function be removed?
Kind regards,
Matthias van de Meent
;t reduce its size while we use attcacheoff for
(de)serialization of tuples with up to MaxAttributeNumber (=INT16_MAX)
of attributes which each can be larger than one byte (such as in
tuplestore, tuplesort, spilling hash aggregates, ...)
Kind regards,
Matthias van de Meent
[0]
https://www.postgr
On Tue, 21 Mar 2023 at 23:05, Andres Freund wrote:
>
> Hi,
>
> On 2023-03-21 21:02:08 +0100, Matthias van de Meent wrote:
> > On Tue, 21 Mar 2023 at 20:58, Andres Freund wrote:
> > > On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote:
> > > > Yes,
On Tue, 21 Mar 2023 at 20:58, Andres Freund wrote:
>
> Hi,
>
> On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote:
> > On Tue, 21 Mar 2023 at 19:55, Tom Lane wrote:
> > >
> > > Andres Freund writes:
> > > > FWIW, I think we sho
ved
"TupleAttrAlignData" structs which carry the
length/alignment/storage/byval info.
Kind regards,
Matthias van de Meent
[0]
https://www.postgresql.org/message-id/CAEze2Wh8-metSryZX_Ubj-uv6kb%2B2YnzHAejmEdubjhmGusBAg%40mail.gmail.com
On Mon, 20 Mar 2023 at 11:11, Tomas Vondra
wrote:
>
> On 3/14/23 15:41, Matthias van de Meent wrote:
> > On Tue, 14 Mar 2023 at 14:49, Tomas Vondra
> > wrote:
> >>
> >>> ...
> >
> >> If you agree with these changes, I'll get it committ
't think we need to be careful
about trashing other workload's buffers if the buffer is useless for
literally every workload.
Kind regards,
Matthias van de Meent
[1]
https://www.postgresql.org/message-id/flat/2023082720.ejifsclfwymw2reb%40awork3.anarazel.de
On Tue, 14 Mar 2023 at 14:49, Tomas Vondra
wrote:
>
>
>
> On 3/8/23 23:31, Matthias van de Meent wrote:
> > On Wed, 22 Feb 2023 at 14:14, Matthias van de Meent
> >
> > I think that the v4 patch solves all comments up to now; and
> > considering that most
On Wed, 22 Feb 2023 at 14:14, Matthias van de Meent
wrote:
>
> On Wed, 22 Feb 2023 at 13:15, Tomas Vondra
> wrote:
> >
> > On 2/20/23 19:15, Matthias van de Meent wrote:
> > > Thanks. Based on feedback, attached is v2 of the patch, with as
> > > significan
On Tue, 7 Mar 2023 at 01:34, Michael Paquier wrote:
>
> On Mon, Mar 06, 2023 at 04:08:28PM +0100, Matthias van de Meent wrote:
> > On Mon, 6 Mar 2023 at 15:40, Bharath Rupireddy
> >> IMO, pg_get_wal_records_extended_info as proposed doesn't look good to
> >> m
On Mon, 6 Mar 2023 at 16:37, Bharath Rupireddy
wrote:
>
> On Mon, Mar 6, 2023 at 8:52 PM Matthias van de Meent
> wrote:
> >
> > On Mon, 6 Mar 2023 at 16:06, Bharath Rupireddy
> > wrote:
> > > If we try to make these functions figure out the oldest WAl file an
n a
system that has experienced timeline switches. It is entirely possible
that the first file (as sorted by the default collation) is not the
first record you can inspect, or even in your timeline's history.
Kind regards,
Matthias van de Meent
n processing on pg_walinspect where they want or need it,
without us having to decide what the user wants, and without having to
associate blocks with the main xlog record data through the joining of
several (fairly expensive) xlog decoding passes.
The basic idea is to create a single entrypoint to all relevant data
from DecodedXLogRecord in SQL, not multiple.
Kind regards,
Matthias van de Meent
On Fri, 3 Mar 2023 at 17:16, Robert Haas wrote:
>
> On Thu, Mar 2, 2023 at 5:47 PM Tom Lane wrote:
> > Harden new test case against force_parallel_mode = regress.
> >
> > Per buildfarm: worker processes can't see a role created in
> > the current transaction.
>
> Now why would that happen? Surely
Hi,
On Thu, 23 Feb 2023 at 17:44, Matthias van de Meent
wrote:
>
> I'll see to further reviewing 0004 and 0005 when I have additional time.
Some initial comments on 0004:
> +/*
> + * brin_minmax_ranges
> + *Load the BRIN ranges and sort them.
> + */
> +D
On Fri, 24 Feb 2023, 20:14 Tomas Vondra, wrote:
>
> On 2/24/23 19:03, Matthias van de Meent wrote:
> > On Thu, 23 Feb 2023 at 19:48, Tomas Vondra
> >> Yeah, that sounds like a bug. Also a sign the tests should have some
> >> by-ref data types (presumably there are
On Thu, 23 Feb 2023 at 19:48, Tomas Vondra
wrote:
>
> On 2/23/23 17:44, Matthias van de Meent wrote:
> > On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
> > wrote:
> >>
> >> On 2/23/23 15:19, Matthias van de Meent wrote:
> >>> Comments on 0001, mo
k = 250
>heapBlk = (250 + 10) % 255 = 5
>
> and we don't do that loop. Or did I get this wrong, somehow?
The result is off-by-one due to (u)int8 overflows being mod-256, but
apart from that your result is accurate.
The condition only stops the loop when we wrap around or when we go
past the last block, but no earlier than that.
Kind regards,
Matthias van de Meent
On Thu, 23 Feb 2023 at 16:22, Tomas Vondra
wrote:
>
> On 2/23/23 15:19, Matthias van de Meent wrote:
>> Comments on 0001, mostly comments and patch design:
One more comment:
>>> + range->min_value = bval->bv_values[0];
>>> + range->max_value = bval
f
the patches are marked WIP. Could you share a status on those, because
currently that status is unknown: Are these patches you don't plan on
including, or are these patches only (or mostly) included for
debugging?
Kind regards,
Matthias van de Meent
On Wed, 22 Feb 2023 at 13:15, Tomas Vondra
wrote:
>
> On 2/20/23 19:15, Matthias van de Meent wrote:
> > Thanks. Based on feedback, attached is v2 of the patch, with as
> > significant changes:
> >
> > - We don't store the columns we mention in predicat
Hi,
On Sun, 19 Feb 2023 at 16:04, Tomas Vondra
wrote:
>
> Hi,
>
> On 2/19/23 02:03, Matthias van de Meent wrote:
> > On Thu, 16 Jun 2022 at 15:05, Tomas Vondra
> > wrote:
> >>
> >> I've pushed the revert. Let's try again for PG16.
> &
ents and polish. I am confident the code is correct,
but not that it is clean (see the commit message of the patch for
details).
Kind regards,
Matthias van de Meent
PS. I'm adding this to the commitfest
Original patch thread:
https://www.postgresql.org/message-id/flat/CAFp7QwpMRGcDAQumN7onN9Hj
;to rip off the band-aid". I'm sending
this mail now to collect community feedback and to make the thread
discoverable in the archives - I can't find any other threads in the
-hackers archives that were created specifically to cover people's
gripes with WAL and solutions to those gr
ovide a reference to this? I have yet to see a COMPRESSED
TABLE feature or syntax, let alone users asking for TOAST to be as
easily usable as that feature or syntax.
Kind regards,
Matthias van de Meent
lightweight and simple to keep rebasing onto the vanilla core.
>
> At least I don't think we should accept such hooks. I don't think I am alone
> in that.
+1
Assuming type-aware TOASTing is the goal, I don't think hooks are the
right design to implement that.
-Matthias van de Meent
n 8kB,
which we'd prefer to compress to the greatest extent possible. So, a
value-level compression method specialized to the type of the value
does make a lot of sense, too.
I'm not trying to say that compressing pages doesn't make sense or is
useless, I just don't think that we should ignore attribute-level
compression just because page-level compression could at some point be
implemented too.
Kind regards,
Matthias van de Meent
On Wed, 1 Feb 2023 at 18:51, Ilya Gladyshev wrote:
>
> 1 февр. 2023 г., в 20:27, Matthias van de Meent
> написал(а):
>
>> In HEAD we set TOTAL to whatever number partitioned table we're
>> currently processing has - regardless of whether we're the top level
On Wed, 1 Feb 2023 at 16:53, Justin Pryzby wrote:
>
> On Wed, Feb 01, 2023 at 04:21:35PM +0100, Matthias van de Meent wrote:
> > On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev
> > wrote:
> > > > 1 февр. 2023 г., в 16:01, Alvaro Herrera
> > > > написал(
> + the total number of leaf partitions on which the index is to be
> created or attached.
I think we should also add a note about the (now) non-constant nature
of the value, something along the lines of "This value is updated as
we're processing and discovering partitioned tables in the partition
hierarchy".
Kind regards,
Matthias van de Meent
On Tue, 31 Jan 2023 at 23:48, Andres Freund wrote:
>
> Hi,
>
> On 2023-01-31 15:05:17 +0100, Matthias van de Meent wrote:
> > If TransactionIdRetreatSafely will be exposed outside procarray.c,
> > then I think the xid pointer should be replaced with normal
> > argu
On Mon, 30 Jan 2023 at 21:19, Andres Freund wrote:
> On 2023-01-10 21:32:54 +0100, Matthias van de Meent wrote:
> > On Tue, 10 Jan 2023 at 20:14, Andres Freund wrote:
> > > On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> > > What precisely do you mean wi
On Fri, 27 Jan 2023 at 16:26, Peter Eisentraut
wrote:
>
> On 12.01.23 14:55, Matthias van de Meent wrote:
> >> Matter of taste, I guess. But more importantly, defining an operator
> >> gives you many additional features that the planner can use to
> >> optimize
On Thu, 26 Jan 2023 at 19:45, Peter Geoghegan wrote:
>
> On Thu, Jan 26, 2023 at 9:53 AM Andres Freund wrote:
> > I assume the case you're thinking of is that pruning did *not* do any
> > changes,
> > but in the process of figuring out that nothing needed to be pruned, we did
> > a
> > MarkBuff
ned the pages, so I suggest plan/scan_pages_eager
and *_lazy as variable names instead, to minimize confusion about the
naming.
I'll await the next iteration of 0002 in which you've completed more
TODOs before I'll dig deeper into that patch.
Kind regards,
Matthias van de Meent
On Sat, 21 Jan 2023 at 02:28, Justin Pryzby wrote:
>
> On Sat, Jan 21, 2023 at 01:51:28AM +0100, Matthias van de Meent wrote:
> > On Thu, 19 Jan 2023 at 06:47, Justin Pryzby wrote:
> > >
> > > pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
>
On Sat, 21 Jan 2023 at 02:04, Ted Yu wrote:
>
>
>
> On Fri, Jan 20, 2023 at 4:51 PM Matthias van de Meent
> wrote:
>>
>> Attached a patch that solves this specific issue in a
>> binary-compatible way. I'm not super happy about relying on behavior
>>
c issue in a
binary-compatible way. I'm not super happy about relying on behavior
of callers of BeginCopyFrom (assuming that users that run copy
concurrently will not provide a ParseState* to BeginCopyFrom), but it
is what it is.
Kind regards,
Matthias van de Meent
v1-0001-Only-report-progress
On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh wrote:
>
> On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
> wrote:
> >
> > On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> > >
> > > Technically correct name of this feature would be Readable Name
the
operator directly if they want more legible operations? So, from your
example, `SELECT box_add(a, b)` instead of `SELECT a :add_point: b`?
I'm -1 on the chosen syntax; :name: shadows common variable
substitution patterns including those of psql.
Kind regards,
Matthias van de Meent
On Tue, 10 Jan 2023 at 20:14, Andres Freund wrote:
>
> Hi,
>
> On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> > On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> > > It's not too hard to fix in individual places, but I suspect that we'll
>
On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> On 2023-01-09 17:50:10 +0100, Matthias van de Meent wrote:
> > Wouldn't it be enough to only fix the constructions in
> > FullXidRelativeTo() and widen_snapshot_xid() (as attached, $topic does
> > not occur with the pat
at can be input for the xid8
> type. But it's hard to believe that'd be a real issue?
Yes, it's unlikely anyone would ever hit that with our current WAL
format - we use 24 bytes /xid just to log it's use, so we'd use at
most epoch 0x1000_ in unrealistic sc
there; the page can't be read by
pageinspect:
$ select get_raw_page('public.something_is_wrong_here', 111)::bytea;
ERROR: invalid page in block 111 of relation base/5/16385
I don't have access to the v14 data anymore (I tried a restart, which
dropped the data :-( ), but will retain my v15 instance for some time to
help any debugging.
Kind regards,
Matthias van de Meent
ete
it.
- Special transaction IDs, their meaning and where they can occur
I can't seem to find any other information in the docs section, and
it is useful to have users understand that certain values are
considered special: FrozenTransactionId and BootstrapTransactionId.
Kind regards,
Matthias van de Meent
ke this wording, but I'm not sure what would be better.
> +cutoffs->MinXid = nextXID - (freeze_table_age * 0.95);
> [...]
> +cutoffs->MinMulti = nextMXID - (multixact_freeze_table_age * 0.95);
Why are these values adjusted down (up?) by 5%? If I configure this
GUC, I'd expect this to be used effectively verbatim; not adjusted by
an arbitrary factor.
---
That's it for now; thanks for working on this,
Kind regards,
Matthias van de Meent
iable length attributes that would be pulled
in with varatt.h. I don't see why we'd call the headers of
variable-length attributes after one small - but not insignifcant -
use case.
Kind regards,
Matthias van de Meent
logged. I
think this should be limited to some degree, such as only freeze
all_visible blocks up to 10% of the table's blocks in eager vacuum, so
that the load is spread across a larger time frame and more VACUUM
runs.
Kind regards,
Matthias van de Meent.
On Mon, 21 Nov 2022 at 12:12, Matthias van de Meent
wrote:
>
> Hi,
>
> I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
> is duplicated above rs_strategy. I don't know if there should have
> been a different comment above rs_strategy, but the current
t was duplicated in c2fe139c20 with the update to the table
scan APIs, which was first seen in PostgreSQL 11.
Kind regards,
Matthias van de Meent
v1-0001-Remove-duplicate-of-comment-under-rs_numblocks.patch
Description: Binary data
ich would be located between pd_upper and pd_special.
>
> I do think that we could indeed use this as an additional in-page
> pointer, but at least for this version was keeping things
> backwards-compatible. Peter G (I think) also made some good points
> about how to include the variou
On Wed, 27 Jul 2022 at 13:34, Matthias van de Meent
wrote:
>
> On Wed, 27 Jul 2022 at 09:35, Matthias van de Meent
> wrote:
> >
> > On Mon, 4 Jul 2022 at 16:18, Matthias van de Meent
> > wrote:
> > >
> > > On Sun, 5 Jun 2022 at 21:12, Matthias van de
s tangentially related to the "nodeToJson
/ changing the storage format of pg_node_tree to json" proposal, but
not the same.
I will add my +1 to Tom's proposal for that function/cast, but I'm not
sure on changing the storage format of pg_node_tree to json.
Kind regards,
Matthias van de Meent
f instability are we talking about? Are there
different results for runs with the same binary, or is this across
compilations?
0003 and up were not yet reviewed in depth.
Kind regards,
Matthias van de Meent
[0]
https://www.postgresql.org/message-id/flat/CA%2BTgmoaCeQ2b-BVgVfF8go8zFoceDjJq9w
On Fri, 21 Oct 2022 at 17:24, Tomas Vondra
wrote:
>
> Hi,
>
> While working on some BRIN code, I discovered a bug in handling NULL
> values - when inserting a non-NULL value into a NULL-only range, we
> reset the all_nulls flag but don't update the has_nulls flag. And
> because of that we then fai
On Mon, 17 Oct 2022 at 05:43, Tomas Vondra
wrote:
>
> On 10/16/22 22:17, Matthias van de Meent wrote:
> > On Sun, 16 Oct 2022 at 16:34, Tomas Vondra
> > wrote:
> >> Try to formulate the whole algorithm. Maybe I'm missing something.
> >>
> >
arge overlapping ranges, as it doesn't need
to copy all tuples that have been read from disk but have not yet been
returned.
The maximum cost of this tuplesort would be the cost of sorting a
seqscanned table, plus sorting the relevant BRIN ranges, plus the 1
extra compare per tuple and range that
have an index that can speed up top-N sorts
without bloating other indexes, and at very low disk footprint.
Columns that are only occasionally accessed in a sorted manner could
then get BRIN minmax indexes to support this sort, at minimal overhead
to the rest of the application.
Kind regards,
Matthias van de Meent
On Wed, 12 Oct 2022 at 23:13, Andres Freund wrote:
>
> Hi,
>
> On 2022-10-12 22:05:30 +0200, Matthias van de Meent wrote:
> > On Wed, 5 Oct 2022 at 01:50, Andres Freund wrote:
> > > I light dusted off my old varint implementation from [1] and converted the
> >
13th, as mentioned in [0].
This same pattern can be seen for minor release versions; where the
release is generally stamped well in advance of the release post going
live.
Kind regards,
Matthias van de Meent
[0] https://postgr.es/m/2a88ff2e-ffcc-bb39-379c-37244b4114a5%40postgresql.org
On Mon, 3 Oct 2022 at 23:26, Andres Freund wrote:
>
> Hi,
>
> On 2022-10-03 19:40:30 +0200, Matthias van de Meent wrote:
> > On Mon, 3 Oct 2022, 19:01 Andres Freund, wrote:
> > > Random idea: xl_prev is large. Store a full xl_prev in the page header,
> > >
but I think it is quite
possible.
Lastly, we could add XLR_BLOCK_ID_DATA_MED for values >255 containing
up to UINT16_MAX lengths. That would save 2 bytes for records that
only just pass the 255B barrier, where 2B is still a fairly
significant part of the record size.
Kind regards,
Matthias van de Meent
), and
one with XID only up to 21 bytes. So, when compared to the current
XLogRecord format, we would in general recover 2 or 3 bytes from the
xl_tot_len field, 1 or 2 bytes from the alignment hole, and
potentially the 4 bytes of the xid when that data is considered
useless during recovery, or p
On Wed, 28 Sept 2022 at 19:40, Bruce Momjian wrote:
>
> On Thu, Sep 22, 2022 at 11:12:32PM +0200, Matthias van de Meent wrote:
> > On Thu, 8 Sept 2022 at 23:24, Tom Lane wrote:
> > >
> > > Matthias van de Meent writes:
> > > > Please find attac
On Tue, 20 Sept 2022 at 17:29, Alvaro Herrera wrote:
>
> On 2022-Sep-20, Matthias van de Meent wrote:
>
> > Allow me to add: compressability
> >
> > In the thread surrounding [0] there were complaints about the size of
> > catalogs, and specifically the templa
for JSON that is only 2 bytes
for each (up to 3 when you consider separators, plus potential extra
overhead for escaped values that are unlikely to appear our catalogs).
Some numbers can be stored more efficiently in JSONB, but only large
numbers and small fractions that we're unlikely t
. (same row)
> > > COMMIT;
> >
> > Didn't we just have this discussion in another thread?
>
> Well. not "just" :)
This recent thread [0] mentioned the same, and I mentioned it in [1]
too last year.
Kind regards,
Matthias
"tab_b_not_null" CHECK (b IS NOT NULL)
"tab_c_not_null" CHECK (c IS NOT NULL)
"tab_d_not_null" CHECK (d IS NOT NULL)
"tab_e_not_null" CHECK (e IS NOT NULL)
But the performance of repeated row-casting would probably not be as
goo
.)
I hadn't realized that triggers indeed consume command ids but might
not be visible to the outer query (that might still be running). That
invalidates the "or (e.g.) the existence of another tuple with the
same XID but with a newer CID" claim I made earlier, so thanks for
clarifying.
Kind regards,
Matthias van de Meent
This means that this needs no
specific handling in the HTSVH code that Laurenz asked about.
Kind regards,
Matthias van de Meent
(e.g.) the
existence of another tuple with the same XID but with a newer CID.
That last one would not be impossible, but probably not worth the
extra cost of command id tracking.
Kind regards,
Matthias van de Meent
tch)insert, update and delete records. It is
based on the changes we made in the fork we maintain for Neon.
Kind regards,
Matthias van de Meent
[0] https://github.com/neondatabase/neon/#neon
[1]
https://github.com/neondatabase/neon/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records
[2
ifies this issue, by moving the XLogBeginInsert()
down to where 1.) we have all relevant buffers pinned and locked, and
2.) we're in a critical section, making that part of the code
consistent with the general scheme for XLog insertion.
Kind regards,
Matthias van de Meent
[0] access/tran
|
COMPRESS_ZSTD)?
Kind regards,
Matthias van de Meent
On Wed, 31 Aug 2022 at 20:56, Andres Freund wrote:
>
> Hi,
>
> On 2022-08-31 19:52:49 +0200, Matthias van de Meent wrote:
> > As for having a lower granularity and preventing the
> > one-syscall-per-Relation issue, can't we reuse the query_start or
> > sta
301 - 400 of 626 matches
Mail list logo
