_MdfdVec *md_seg_fds[MAX_FORKNUM + 1];
> + SMgrId smgr_which; /* storage manager selector */
> + int smgrrelation_size; /* size of this struct,
> incl. smgr-specific data */
It looked to me like you determined this globally - why do we need it in every
entry then?
Greetings,
Andres Freund
... PRIMARY KEY USING INDEX ...;
we could just do something similar for the NOT NULL constraint? Which would
then delete the separate constraint NOT NULL constraint.
Greetings,
Andres Freund
Hi,
On 2023-06-30 16:28:59 -0500, David Christensen wrote:
> On Fri, Jun 30, 2023 at 3:29 PM Andres Freund wrote:
> >> And indeed. Comparing e.g. TPC-H, I see *massive* regressions. Some
> >> queries
> > are the same, sobut others regress by up to 70% (although more
Hi,
On 2023-06-30 18:58:20 -0400, Bruce Momjian wrote:
> > [1] On linux I think you need to use stat() to figure out the st_dev for a
> > file, then look in /proc/self/mountinfo for the block device, use the name
> > of the file to look in /sys/block/$d/queue/physical_block_size.
>
> I just got a
On 2023-06-30 18:37:39 -0400, Bruce Momjian wrote:
> On Sat, Jul 1, 2023 at 12:21:03AM +0200, Tomas Vondra wrote:
> > On 6/30/23 23:53, Bruce Momjian wrote:
> > > For a 4kB write, to say it is not partially written would be to require
> > > the operating system to guarantee that the 4kB write is
Hi,
On 2023-06-30 17:53:34 -0400, Bruce Momjian wrote:
> On Fri, Jun 30, 2023 at 11:42:30PM +0200, Tomas Vondra wrote:
> > On 6/30/23 23:11, Andres Freund wrote:
> > > I suspect you're going to see more benefits from going to a *lower*
> > > setting
> > > than
orrect.
Yea, it's not trivial. And the downsides are also substantial from a
replication / crash recovery performance POV - even with reading blocks ahead
of WAL replay, it's hard to beat just sequentially reading nearly all the data
you're going to need.
> On 6/30/23 23:11, Andres Freund wrote:
&
Hi,
On 2023-06-30 23:27:45 +0200, Tomas Vondra wrote:
> On 6/30/23 23:11, Andres Freund wrote:
> > ...
> >
> > If we really wanted to do this - but I don't think we do - I'd argue for
> > working on the buildsystem support to build the postgres binary multiple
> &
I really
don't see us ever wanting to make BLCKSZ runtime configurable within one
postgres binary. There's just too much intrinsic overhead associated with
that.
Greetings,
Andres Freund
W, you seriously need to evaluate analytics queries before this is worth
looking at further.
Greetings,
Andres Freund
we don't immediately find
them, because it's almost guaranteed to cause some.
Besides this, I've not really heard any convincing justification for needing
this in the first place.
Greetings,
Andres Freund
Hi,
On 2023-06-30 14:13:11 +1200, Thomas Munro wrote:
> On Fri, Jun 30, 2023 at 3:39 AM Andres Freund wrote:
> > I am wondering if we don't want something more generic than stashing this in
> > rd_amcache. Don't want to end up duplicating relevant code across the uses
> &
Hi,
On 2023-06-29 11:58:27 +0200, Tomas Vondra wrote:
> On 6/29/23 01:34, Andres Freund wrote:
> > On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> >> Yeah. FWIW I was interested what the patch does in practice, so I
> >> checked what pahole says a
iously beneficial.
FWIW, it seems it could be handled somewhat centrally for binaries, the
bin_targets array should have all that's needed?
Some things won't work from the build directory, btw. E.g. initdb or postgres
itself.
Greetings,
Andres Freund
rably harder sell for people to migrate.
I.e. I considered it, but due to meson's "no outputs outside of the current
directory" rule, it didn't (and sadly still doesn't) really seem viable.
Greetings,
Andres Freund
Hi,
On 2023-06-29 13:34:42 -0500, Tristan Partin wrote:
> On Thu Jun 29, 2023 at 12:35 PM CDT, Andres Freund wrote:
> > > v5-0012-Make-finding-pkg-config-python3-more-robust.patch
> >
> > The commit message here is clearly outdated (still talking about Python.h
>
uot;if
feature.disabled()" actually leads to tests being executed when a feature is
disabled, e.g. perl -MConfig ... would now be run even perl is disabled.
Attached my version of 0007 and 0011 (with some changes from 0012 and
0015). I'm running a test of those with the extended CI
gt; + /* Is it still valid and holding the right tag? */
> + if (PinBuffer(bufHdr, NULL, true))
I do wonder if we should have an unlocked pre-check for a) the buffer being
valid and b) BufferTagsEqual() matching. With such a pre-check the race for
increasing the usage count of the wrong buffer is quite small, without the
pre-check it doesn't seem that small anymore.
Greetings,
Andres Freund
he smaller size classes, but above 64-256 bytes or such, I
think the wins might be big enough to outweight the costs?
Of course that doesn't guarantee that that memory in those smaller size
classes is going to be used...
Greetings,
Andres Freund
Which also would get rid of the concerns around needing a
"mini_size_t" type.
- freeListIndex could be a single byte as well (saving 7 bytes, as right now
we loose 4 trailing bytes due to padding).
That would save another 12 bytes, if I calculate correctly. 25% shrinkage
together ain't bad.
Greetings,
Andres Freund
en
though it doesn't help. And it will be very heavily dependent on the OS and
glibc version.
> Le mardi 27 juin 2023, 20:17:46 CEST Andres Freund a écrit :
> > > Except if you hinted we should write our own directly instead ?
> > > > We e.g. could keep a larger number of m
Hi,
On 2023-06-28 10:40:22 +0200, Peter Eisentraut wrote:
> On 26.06.23 21:54, Andres Freund wrote:
> > For something like pg_list.h the malloc(free) attribute is a bit awkward to
> > use, because one a) needs to list ~30 functions that can free a list and b)
> > the refe
Hi,
This discussion started at
https://postgr.es/m/20230627212423.p56zxuqeh5kya...@awork3.anarazel.de
but isn't really related to the bug.
On 2023-06-27 17:44:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > That's not going to help you / the reporter, but to make is
Hi,
On 2023-06-27 08:35:28 +0200, Ronan Dunklau wrote:
> Le lundi 26 juin 2023, 23:03:48 CEST Andres Freund a écrit :
> > Hi,
> >
> > On 2023-06-26 08:38:35 +0200, Ronan Dunklau wrote:
> > > I hope what I'm trying to achieve is clearer that way. Maybe this patch i
Hi,
On 2023-06-27 01:10:25 -0700, Peter Geoghegan wrote:
> On Mon, Jun 26, 2023 at 11:27 PM Andres Freund wrote:
> > On 2023-06-26 21:53:12 -0700, Peter Geoghegan wrote:
> > > It should be safe to allow searchers to see a version of the root page
> > > that is ou
Hi,
On 2023-06-27 19:04:31 +0300, Ants Aasma wrote:
> On Tue, 27 Jun 2023 at 18:40, Andres Freund wrote:
> > On 2023-06-27 14:49:48 +0300, Ants Aasma wrote:
> > > If you want to experiment, here is a rebased version of something I
> > > hacked up a couple of years back
t difference.
Thanks for posting!
Based on past experiments, anything that requires an atomic op during spinlock
release on x86 will be painful :/. I'm not sure there's a realistic way to
avoid that with futexes though :(.
Greetings,
Andres Freund
weakened in some way that might complicate this approach.
> Searchers need to check the high key to determine if they need to move
> right -- same as always.
Wouldn't we at least need a pin on the root page, or hold a snapshot, to
defend against page deletions?
Greetings,
Andres Freund
Hi,
On 2023-06-27 16:40:08 +1200, Thomas Munro wrote:
> On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan wrote:
> > On Mon, Jun 26, 2023 at 9:09 PM Andres Freund wrote:
> > > I think we should be able to have a post-check that can figure out
> > > if the copied roo
Hi,
On 2023-06-27 15:33:57 +1200, Thomas Munro wrote:
> On Tue, Jun 27, 2023 at 2:05 PM Andres Freund wrote:
> > Unfortunately it scaled way worse at first. This is not an inherent issue,
> > but
> > due to an implementation choice in ReadRecentBuffer(). Whereas the n
win. About 7% in
a concurrent, read-only pgbench that utilizes batches of 10. And it should be
easy to get much bigger wins, e.g. with a index nested loop with a relatively
small index on the inner side.
Greetings,
Andres Freund
[1]
https://www.postgresql.org/message-id/20230627013458
also
reset when pgstat_report_activity(STATE_RUNNING) is called.
I think this means that e.g. bgworkers issuing queries will often get stuck
on the first query_id used, unless they call pgstat_report_activity()?
Greetings,
Andres Freund
[1] https://twitter.com/MengTangmu/status/1673439083518115
XLogRecordBuffer *buf)
> switch (info)
> {
> case XLOG_HEAP2_MULTI_INSERT:
> - if (!ctx->fast_forward &&
> - SnapBuildProcessChange(builder, xid,
> buf->origptr))
> + if (SnapBuildProcessChange(builder, xid, buf->origptr))
> DecodeMultiInsert(ctx, buf);
> break;
> case XLOG_HEAP2_NEW_CID:
> --
> 2.30.2
LGTM^2
Greetings,
Andres Freund
it's pretty rare. It's one thing to decide to backpatch an
optimization if it had time to "mature" in the development branch, but from
what I undestand you're proposing to apply this just to the back branches.
Greetings,
Andres Freund
the results immediately.
Greetings,
Andres Freund
that don't require digging
into the archive to find an email by David?
Greetings,
Andres Freund
larly
> > where plans (and JIT?) might be cached, could well save us (depending
> > on workload).
>
> TBH I do not find this proposal attractive in the least.
Yea, me neither. It doesn't address any of the actual problems and will add
new contention.
Greetings,
Andres Freund
inserts (which wouldn't trigger
autovacuum analyzing) would lead to the "0 rows" stats causing very bad plans.
Greetings,
Andres Freund
ut a
recent gcc (likely >= 12).
Do others think this would be useful enough to be worth polishing? And do you
agree the warnings above are bugs?
Greetings,
Andres Freund
>From e05c1260ee70457e9a899d5c32e5b85702193739 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Mon, 26 Jun 2023 12
Hi,
On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
> I'm hacking on this bugfix again, thanks to Evgeny's reminder on the other
> thread [1].
>
>
> I've been adding checks for partiall-dropped databases to the following places
> so far:
> - vac_truncate_clog(), as aut
Hi,
On 2023-06-23 18:41:58 -0700, Andres Freund wrote:
> I guess this might be caused by 78db307bb23 adding the check, but using
> GetOldestXmin(NULL, true) to determine lastSaneFrozenXid. That was changed
> soon after, in 87f830e0ce03.
FWIW, the discussion leading up to 87f830e0ce03
Hi,
On 2023-06-21 21:50:39 -0700, Noah Misch wrote:
> On Wed, Jun 21, 2023 at 05:46:37PM -0700, Andres Freund wrote:
> > A related issue is that as far as I can tell the determination of what is
> > bogus is bogus.
> >
> > The relevant cutoffs are determined vac_
makes the meson build work correctly even with SIP enabled. The trick is
basically to change the absolute references to libraries to relative ones.
Except for a small amount of complexity during install, I don't think this has
a whole lot of downsides. Making the install relocatable imo is pretty nice.
I guess I should repost that for 17...
Greetings,
Andres Freund
d version, when the existing testing clearly wasn't enough to find the
current bug, doesn't strike me as wise.
Greetings,
Andres Freund
e newer clang version, it
might also make sense to just use it from a simplicity perspective
(e.g. compiler warnings being the same etc), but it's not required. It works
just fine to compile the postgres binary with gcc and use clang for the
bitcode after all.
Greetings,
Andres Freund
Hi,
On 2023-06-21 21:50:39 -0700, Noah Misch wrote:
> On Wed, Jun 21, 2023 at 03:12:08PM -0700, Andres Freund wrote:
> > When vac_truncate_clog() returns early
> ...
> > we haven't released the lwlock that we acquired earlier
>
> > Until there's some ca
Hi,
On 2023-06-22 10:00:01 +0530, Amit Kapila wrote:
> On Wed, Jun 21, 2023 at 11:53 AM Peter Geoghegan wrote:
> >
> > On Tue, Jun 20, 2023 at 10:27 PM Andres Freund wrote:
> > > As far as I can tell 72e78d831a as-is is just bogus. Unfortunately that
> > > l
t open coding it in a tap test seems to be the best way?
Is it worth doing?
Greetings,
Andres Freund
Hi,
On 2023-06-21 15:12:08 -0700, Andres Freund wrote:
> When vac_truncate_clog() returns early, due to one of these paths:
>
> [...]
>
> Separately, I think it's quite bad that we *silently* return from
> vac_truncate_clog() when finding a bogus xid. That's a quite severe cond
om
vac_truncate_clog() when finding a bogus xid. That's a quite severe condition,
we should at least tell the user about it.
Greetings,
Andres Freund
[1] https://postgr.es/m/20230621190204.nsaelabojxppiuix%40awork3.anarazel.de
g anything touching it - I think
it might be reasonable to just open-code fetching datconnlimit :/.
This patch is starting to be a bit big, particularly once adding tests for all
the checks mentioned above - but I haven't heard of or thought of a better
proposal :(.
Greetings,
Andres Freund
; Backpatching the OPENSSL_API_COMPAT change would set the minimum OpenSSL
> version to 1.0.1, which is newer than what was so far required in those
> branches. That is the reason we didn't do this.
What's the problem with just setting a different version in those branches?
Greetings,
Andres Freund
_openssl.c. Thoughts about doing something like the attached for
> ~13?
Wouldn't the proper fix be to backpatch 4d3db13621b? Just suppressing all
deprecations doesn't strike me as particularly wise, especially because we've
chosen a different path for 14+?
Greetings,
Andres Freund
east something that makes such "ignored errors" visible from stats.
Greetings,
Andres Freund
tbl_foo_idx ON tbl_foo USING gin (foo) WITH (fastupdate = on);
INSERT INTO tbl_foo(foo) VALUES ('ab'), ('a'), ('b'), ('c');
SELECT gin_clean_pending_list('tbl_foo_idx');
As far as I can tell 72e78d831a as-is is just bogus. Unfortunately that likely
also means 3ba59ccc89 is not right.
Greetings,
Andres Freund
Hi,
On 2023-06-21 08:54:48 +0530, Amit Kapila wrote:
> On Mon, Jun 19, 2023 at 11:47 PM Andres Freund wrote:
> >
> > On June 19, 2023 10:37:45 AM PDT, Tom Lane wrote:
> > >Andres Freund writes:
> > >> Unfortunately, due to some personal
Hi,
On 2023-06-21 09:35:36 +0700, John Naylor wrote:
> On Wed, Jun 21, 2023 at 12:46 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2023-06-20 10:29:41 -0700, Andres Freund wrote:
> > > On 2023-06-20 10:23:14 +0700, John Naylor wrote:
> > > > Her
Hi,
On 2023-06-20 10:29:41 -0700, Andres Freund wrote:
> On 2023-06-20 10:23:14 +0700, John Naylor wrote:
> > Here's a start at that, trying with postmaster only. Unfortunately, I get
> > "MADV_COLLAPSE failed: Invalid argument".
>
> I also see that. But dep
lable
I suspect there's some kernel issue. I'll try to ping somebody.
Greetings,
Andres Freund
Hi,
On June 19, 2023 10:37:45 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> Unfortunately, due to some personal life business, it took until for me to
>> feel comfortable pushing the fix for
>> https://www.postgresql.org/message-id/zezdj1h61ryrm...@msg.df7cb.de
>>
is wrapped? I did a bunch of CI runs
with the patch and patch + test infra, and they all passed.
Greetings,
Andres Freund
>From 6e67692231de22b6e347d330aacad72a6fdbd89a Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Mon, 19 Jun 2023 10:26:30 -0700
Subject: [PATCH v2] fd.c: Retry after EI
Hi,
On 2023-06-19 09:46:12 -0400, Robert Haas wrote:
> On Wed, Jun 14, 2023 at 4:40 PM Andres Freund wrote:
> > > But I'm not sure that's a great approach, because that LSN gap might be
> > > large and then we're duplicating a lot of work that the summarizer has
> > &
le. I don't see a problem with rerunning genbki.pl et al
after
somebody updates File::Compare?
Greetings,
Andres Freund
Hi,
On 2023-06-14 16:10:38 -0400, Robert Haas wrote:
> On Wed, Jun 14, 2023 at 3:47 PM Andres Freund wrote:
> > Could we just recompute the WAL summary for the [redo, end of chunk] for the
> > relevant summary file?
>
> I'm not understanding how that would help. If we
; branch, per the
> attached patch.
Seems like a good idea - I can't think of a reason why we shouldn't do so.
Greetings,
Andres Freund
h DSM.
>
> With the process model, that local stuff are flushed out upon
> reconnection. If we switch to the thread model, we will need an
> expiration mechanism for those stuff.
Isn't that just doing something like MemoryContextDelete(TopMemoryContext) at
the end of proc_exit() (or it's thread equivalent)?
Greetings,
Andres Freund
ol.
I don't know the tar format well, but my understanding is that it doesn't have
a "central metadata" portion. I.e. doing something like this would entail
scanning the tar file sequentially, skipping file contents? And wouldn't you
have to create an entirely new tar file for the modified output? That kind of
makes it not so incremental ;)
IOW, I'm not sure it's worth bothering about this ever, and certainly doesn't
seem worth bothering about now. But I might just be missing something.
Greetings,
Andres Freund
Hi,
On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
> On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
> > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
> > > &g
Hi,
On 2023-06-14 12:40:18 +0700, John Naylor wrote:
> On Sat, Nov 5, 2022 at 3:27 PM Andres Freund wrote:
>
> >/*
> > * Make huge pages out of it. Requires at least linux 6.1. We
> could
> > * fall back to MADV_HUGEPAGE if it f
Hi,
On 2023-06-13 20:55:19 +0200, Magnus Hagander wrote:
> On Tue, Jun 13, 2023 at 6:59 PM Andres Freund wrote:
> >
> > Hi,
> >
> > I just helped somebody debug a postgres performance problem that turned out
> > to
> > be not actually be postgres' fault
destination.
That's not perfect - we'd e.g. still not be able to debug where the logger
process is stuck, due it not being in pg_stat_activity. But other processes
reporting the wait event for writing to the logger process would be a pretty
good hint.
Greetings,
Andres Freund
updates, we will be satisfied with it.
>
> The patch is quite simple and looks good to me. (At least way better
> than always using GetCurrentTimestamp():)
Thanks for looking - I already had pushed the commit by the time I read your
email, otherwise I'd have mentioned you reviewing it..
ared between the processes etc.
Eventually this could include removing the 1:1 connection<->process/thread
model. That's possible to do with processes as well, but considerably
harder.
2) Making context switches cheaper / sharing more resources at the OS and
hardware level.
Greetings,
Andres Freund
Hi,
On 2023-06-12 11:54:42 -0500, Tristan Partin wrote:
> On Fri Jun 9, 2023 at 1:36 PM CDT, Andres Freund wrote:
> > The biggest change to make them more usable would be to properly reconfigure
> > when the contents of machine file change. IIRC configure is rerun, but the
>
Hi,
Small update for posterity:
On 2022-09-09 16:58:36 -0700, Andres Freund wrote:
> I've run this through enough attempts by now that I'm quite confident that the
> problem does not occur when the errormode does not include
> SEM_NOOPENFILEERRORBOX. I'll want a few more runs to b
gt; That's certainly a good idea. I'll do that in the next round of tests. I
> also plan to do a test on data set that fits into RAM, to test "properly
> cached" case.
Cool. It'd be good to measure both the case of all data already being in s_b
(to see the overhead of the buffer mapping lookups) and the case where the
data is in the kernel pagecache (to see the overhead of pointless
posix_fadvise calls).
Greetings,
Andres Freund
slow if
a lot of transactions are in progress concurrently. As soon as the clog
buffers are extended all time is spent copying pages from the kernel
pagecache. I'd not at all be surprised if this changed causes a substantial
slowdown in workloads with lots of small transactions, where most transactio
Hi,
On 2023-06-10 12:48:46 -0700, Andres Freund wrote:
> > +
> > +
> > +
>
> Hm - why is all of this stuff even ending up in the external ABI? It should
> all be internal, unless I am missing something?
>
> I might be looking the wrong way,
06fd8'>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
Hm - why is all of this stuff even ending up in the external ABI? It should
all be internal, unless I am missing something?
I might be looking the wrong way, but to me it sure looks like none of that
ends up being externally visible?
Greetings,
Andres Freund
nt
> +pg_tss_set(pg_tss_t key, void *value)
> +{
> +#ifdef WIN32
> + return FlsSetValue(key, value) ? pg_thrd_success : pg_thrd_error;
> +#else
> + return pg_thrd_maperror(pthread_setspecific(key, value));
> +#endif
> +}
It's somewhat annoying that this can return errors.
> +static inline int
> +pg_mtx_init(pg_mtx_t *mutex, int type)
I am somewhat confused by the need for these three letter
abbreviations... Blaming C11, not you, to be clear.
>
> -# port needs to be in include path due to pthread-win32.h
> +# XXX why do we need this?
> libpq_inc = include_directories('.', '../../port')
> libpq_c_args = ['-DSO_MAJOR_VERSION=5']
Historically we need it because random places outside of libpq include
pthread-win32.h - but pthread-win32.h is in src/port, not in
src/include/port. Why on earth it was done this way, I do not know.
Greetings,
Andres Freund
Hi,
On 2023-06-09 12:23:36 -0700, Peter Geoghegan wrote:
> On Fri, Jun 9, 2023 at 12:03 PM Andres Freund wrote:
> > > My new plan is to commit this tomorrow, since the clear consensus is
> > > that we should go ahead with this for 16.
> >
> > I'm not sure the
Hi,
On 2023-06-06 21:53:00 +0200, Alvaro Herrera wrote:
> On 2023-Apr-24, Andres Freund wrote:
>
> > A prototype of that approach is attached. I pushed the retry handling into
> > the
> > pg_* routines where applicable. I guess we could add pg_* routines for
> >
Hi,
On 2023-05-22 13:36:42 +0900, Kyotaro Horiguchi wrote:
> At Sun, 21 May 2023 15:14:23 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > I don't really feel confident we're going to get the timeout approach solid
> > enough for something going into the tree aro
ng of various PostgreSQL
features that are not built by default. Most of these are non-default only
because they require additional software, as described in Section 17.1."
So just merging --without-icu, --without-readline, --without-zlib,
--disable-thread-safety, in with the rest doesn't quite seem right.
I suspect that the easiest way for that is to just move --disable-atomics,
--disable-spinlocks to the developer section and then to leave the
anti-features section around for autoconf.
Any better idea?
Greetings,
Andres Freund
Hi,
On 2023-06-09 13:58:46 -0500, Tristan Partin wrote:
> Patch looks good to me!
Thanks for the report Ilmari and the review Tristan! Pushed the fix.
Regards,
Andres
> int sortopt);
I think we should continue to provide the table here, even if we don't need it
today.
Greetings,
Andres Freund
Hi,
On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
> On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
> > Hi,
> >
> > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
> > > > I wonder if we instead could just make perl output the files it
Hi,
On 2023-06-09 13:15:27 -0500, Tristan Partin wrote:
> On Fri Jun 9, 2023 at 11:41 AM CDT, Andres Freund wrote:
> > I like the current version better - depending on the meson version makes it
> > easy to find what needs to be removed when we upgrade the meson minimum
> >
Hi,
On 2023-06-07 18:45:07 -0700, Noah Misch wrote:
> On Wed, Jun 07, 2023 at 04:47:26PM -0700, Andres Freund wrote:
> > On 2023-06-07 16:14:07 -0700, Noah Misch wrote:
> > > A postgres.exe built with meson, ninja, and MSVC lacks the version
> > > metadata
> > &
r specifying
> paths
>
> Meson has a built-in way to override paths without polluting project
> build options called machine files.
I think meson machine files are just about unusable. For one, you can't
actually change any of the options without creating a new build dir. For
another, it's not something that easily can be done on the commandline.
So I really don't want to remove these options.
Greetings,
Andres Freund
Hi,
On 2023-06-08 20:20:18 -0400, Gregory Smith wrote:
> On Thu, Jun 8, 2023 at 6:18 PM Andres Freund wrote:
>
> > Could you get a profile with call graphs? We need to know what leads to all
> > those osq_lock calls.
> > perf record --call-graph dwarf -a sleep 1
> &g
should eliminate most of this, I think.
I'm a bit confused by some of these numbers. How can OS-level prefetching lead
to massive prefetching in the alread cached case, e.g. in tpch q06 and q08?
Unless I missed what "xeon / cached (speedup)" indicates?
I think it'd be good to run a performance comparison of the unpatched vs
patched cases, with prefetching disabled for both. It's possible that
something in the patch caused unintended changes (say spilling during a
hashagg, due to larger struct sizes).
Greetings,
Andres Freund
Hi,
On 2023-06-08 15:18:07 -0700, Andres Freund wrote:
> E.g. on my workstation (two sockets, 10 cores/20 threads each), with 32
> clients, performance changes back and forth between ~600k and ~850k. Whereas
> with 42 clients, it's steadily at 1.1M, with little variance.
FWIW, this is w
when the memory controller is enabled. IIRC that could be alleviated
to a substantial degree with cgroup.memory=nokmem.
Greetings,
Andres Freund
ferent PCIDs.
> The only way to avoid TLB shootdowns on context switches is to have *exactly
> the same memory map*. Or, as Robert succinctly shouted, "THREADS".
+1
Greetings,
Andres Freund
he industry have decided isn't going anywhere. It'd be one
thing if we had 5 kernel devs that we could deploy to work on this, but we
don't. So we have to convince kernel devs employed by others that somehow this
is an urgent enough thing that they should work on it. The likely, imo
justified, answer is just going to be: Fix your architecture, then we can
talk.
Greetings,
Andres Freund
ed via process exit, making the change
realistically reviewable, portability are all much harder.
Greetings,
Andres Freund
and they are primarily interested in
changing properties of a memory mapping across multiple processes, e.g. making
some memory executable and have that reflected in all processes. I don't think
this will help us much.
Greetings,
Andres Freund
rcx, __emutls_v.c[rip]
add DWORD PTR [rax], 1
call__emutls_get_address
add DWORD PTR [rax], 1
add rsp, 40
ret
Greetings,
Andres Freund
Hi,
On 2023-06-08 12:15:58 +0200, Hannu Krosing wrote:
> On Thu, Jun 8, 2023 at 11:54 AM Hannu Krosing wrote:
> >
> > On Wed, Jun 7, 2023 at 11:37 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2023-06-05 13:40:13 -0400, Jonat
801 - 900 of 8831 matches
Mail list logo
