database.
On Fri, Jul 25, 2025 at 10:43 AM Hannu Krosing wrote:
>
> I have been thinking of this from a little different direction. We
> already have all the needed functionality in pg_dump so why not just
> have an option to do
>
> CREATE EXTENSION pg_dump;
>
> Whi
I have been thinking of this from a little different direction. We
already have all the needed functionality in pg_dump so why not just
have an option to do
CREATE EXTENSION pg_dump;
Which would wrap and expose whatever the current version of pg_dump is doing.
It still would need to resolve the
I had left plain < and > in code sample in documentation page, fixed now
On Sun, Jul 6, 2025 at 11:52 PM Hannu Krosing wrote:
>
> On Sat, Feb 3, 2024 at 8:54 AM Hannu Krosing wrote:
> >
> > My justification for adding pl/pgsql tests as part of the immediately
> &g
On Tue, Jul 22, 2025 at 1:24 PM Nikita Malakhov wrote:
>
> Hi Michael!
>
> Yes, I know about relation rewrite and have already thought about how
> we can avoid excessive storage of toastrelid and do not spoil rewrite,
> still do not have a good enough solution.
The high-level idea would be to any
I have been evolving details for Direct TOAST design in
https://wiki.postgresql.org/wiki/DirectTOAST
The top level goals are
* 8-byte TOAST pointer - just (header:1, tag:1 and TID:6)
* all other info moved from toast pointer to actual toast record(s),
so heap rows are smaller and faster.
* all ex
Do you think the current patch could be backported to at least some
latest versions ?
On Fri, Jul 18, 2025 at 6:05 PM Nathan Bossart wrote:
>
> Committed.
>
> I'm cautiously optimistic that we can find some better gains for upgrades
> from v16 and newer. That would involve dumping lo_create() co
On Mon, Jul 14, 2025 at 8:15 AM Nikita Malakhov wrote:
>
...
> Have to mention though that we encountered issues in logical replication
> when we made toast values updatable.
This seems to indicate that Logical Decoding does not honour
visibility checks in TOAST.
This works fine if the TOAST visi
On Fri, Jul 18, 2025 at 9:24 PM Nikita Malakhov wrote:
>
> Hi Michael,
>
> I'm currently debugging POC direct tids TOAST patch (on top of your branch),
> will mail it in a day or two.
Great!
I also just started looking at it, starting from 0003 as recommended by Michael.
Will be interesting to
Ah, I see.
I retried and now it runs for 21 to 29 seconds for 1 million large
objects with two grants each, 3M total rows inserted.
Yesterday it ran 8 seconds. Unfortunately I do not have the plan from
yesterday saved .
Anyway it looks like just dumping pg_shdepend it is better, and likely
also
On Tue, Jul 8, 2025 at 11:06 PM Nathan Bossart wrote:
>
> On Sun, Jul 06, 2025 at 02:48:08PM +0200, Hannu Krosing wrote:
> > Did a quick check of the patch and it seems to work ok.
>
> Thanks for taking a look.
>
> > What do you think of the idea of not dumping pg_shd
Yes, this should say average
On Wed, Jul 9, 2025 at 8:42 AM Laurenz Albe wrote:
>
> On Tue, 2025-07-08 at 18:17 -0400, Tom Lane wrote:
> > One other thing that bothers me as I look at the output is
> >
> > Per loop time including overhead: 731.26 ns
> >
> > That's stated in a way that makes
chunk_
On Tue, Jul 8, 2025 at 9:37 PM Álvaro Herrera wrote:
>
> On 2025-Jul-08, Hannu Krosing wrote:
>
> > I still think we should go with direct toast tid pointers in varlena
> > and not some kind of oid.
>
> I think this can be made to work, as long as we stop se
On Tue, Jul 8, 2025 at 8:07 PM Tom Lane wrote:
>
> BTW, returning to the original topic of this thread:
>
> The new exact-delays table from pg_test_timing is really quite
> informative.
Maybe we should collect some of it in the PostgreSQL Wiki for easy reference ?
I had some interesting results
I still think we should go with direct toast tid pointers in varlena
and not some kind of oid.
It will remove the need for any oid management and also will be
many-many orders of magnitude faster for large tables (just 2x faster
for in-memory small tables)
I plan to go over Michael's patch set he
On Mon, Jul 7, 2025 at 11:38 PM Tom Lane wrote:
>
> > Also added a flag to select number of direct values to show
>
> Hmm ... I agree with having a way to control the length of that output,
> but I don't think that specifying a count is the most useful way to
> do it. Particularly with a default
On Sat, Feb 3, 2024 at 8:54 AM Hannu Krosing wrote:
>
> My justification for adding pl/pgsql tests as part of the immediately
> available tests
> is that pl/pgsql itself is always enabled, so having a no-effort way to test
> its
> performance benefits would be really helpful
Here is the latest patch with documentation only for the utility
itself. Old general discussion moved to PostgreSQL Wiki with link to
it in "See Also " section
Also added a flag to select number of direct values to show
On Sun, Nov 3, 2024 at 11:19 PM Tom Lane wrote:
>
> Hannu
And now it also passes tests.
Still learning about the git way of generating PostgreSQL patches,
that's why there are two separate ones
On Sun, Jul 6, 2025 at 4:30 PM Hannu Krosing wrote:
>
> Managed to send wrong patch earlier, this one actually compiles
>
> On Sun, Jul 6
Managed to send wrong patch earlier, this one actually compiles
On Sun, Jul 6, 2025 at 1:48 PM Hannu Krosing wrote:
>
> Here is a rebased patch
>
> this time I did not indent the part under
> if(SessionReplicationRole != SESSION_REPLICATION_ROLE_REPLICA)
> {
> ... (
> }
Hi Nathan,
Did a quick check of the patch and it seems to work ok.
What do you think of the idea of not dumping pg_shdepend here, but
instead adding the required entries after loading
pg_largeobject_metadata based on the contents of it ?
The query for this would be
WITH db AS (
SELECT oid F
, 2025 at 4:02 PM Hannu Krosing wrote:
>
> I would also argue for treating this as a bug and back-porting to all
> supported versions - a quick look at v13 seems to confirm that the
> wrapped code has not changed at least since then.
>
> I don't think we can claim the curr
Hi Michael
I'll take a look at the patch set.
While digging around in the TOAST code did you have any ideas on how
one could extract the TOAST APIs in a way that they can be added in
Table Access Method definition ?
Not all TAMs need TOAST, but the ones that do could also be the ones
that still
I have added this to the commitfest
We would be grateful for any reviews and feedback on this.
When adding to commitfest I tried to put Nitin as "first author" as he
has done the bulk of the work (I did just a quick pg_dump-only PoC)
but it looks like Commitfest just orders all provided authors
a
they really intended it to work this
way :)
On Sat, May 24, 2025 at 3:47 PM Hannu Krosing wrote:
>
> Hello Everybody,
>
> Currently setting `session_replication_role` to `replica` disables
> foreign key checks allowing, among other things, free table copy order
> and fast
Hello Everybody,
Currently setting `session_replication_role` to `replica` disables
foreign key checks allowing, among other things, free table copy order
and faster CDC apply in logical replication.
But two other cases of foreign keys are still restricted or blocked
even with this setting
1. F
Thanks a lot!
On Tue, May 20, 2025 at 9:42 AM Tomas Vondra wrote:
>
> On 5/20/25 08:49, Hannu Krosing wrote:
> > Hi to all note-takers
> >
> > (I added two who I *think* I remember took notes)
> >
> > Please upload the notes to the Unconference section in
Hi to all note-takers
(I added two who I *think* I remember took notes)
Please upload the notes to the Unconference section in
https://wiki.postgresql.org/wiki/PGConf.dev_2025
I have also some random notes on scraps of paper from the two sessions
I attended and did not present and would like to
Have you also checked out
https://github.com/postgrespro/pg_query_state which logs running query
plan AND collected counts and timings as a response to a signal?
Has this ever been discussed for inclusion in core ?
On Thu, Apr 24, 2025 at 2:49 PM torikoshia wrote:
>
> Hi,
>
> Attached a rebased
If there are no objections we will add this to the commitfest
On Mon, Apr 7, 2025 at 9:48 PM Hannu Krosing wrote:
>
>
> Just to bring this out separately : Does anybody have any idea why pipe
> commands close inside tests ?
>
> Re: 003-pg_dump_basic_tests has a few basic va
On Wed, Apr 16, 2025 at 6:27 AM Tom Lane wrote:
>
> Andrey Borodin writes:
> > I think it's what Konstantin is proposing. To have our own Raft
> > implementation, without dependencies.
>
> Hmm, OK. I thought that the proposal involved relying on some existing
> code, but re-reading the thread t
And in case there *is* ACL present then each user mentioned in the ACL
adds more overhead
Also the separate GRANT calls cause bloat as the
pg_largeoject_metadata row gets updated for each ALTER USER or GRANT
The following is for 10 million LOs with 1 and 3 users being GRANTed
SELECT on each objec
On Tue, Apr 8, 2025 at 7:07 PM Tom Lane wrote:
>
> Nathan Bossart writes:
> > I do think it's worth considering going back to copying
> > pg_largobject_metadata's files for upgrades from v16 and newer.
>
> (If we do this) I don't see why we'd need to stop at v16. I'm
> envisioning that we'd use
On Tue, Apr 8, 2025 at 8:39 PM Nathan Bossart wrote:
>
...
>
> I've also verified that the dependency information is carried over in
> upgrades to later versions (AFAICT all the supported ones).
If I remember correctly the change to not copying
pg_largeobject_metadata data file but instead moving
commands), that might change at some point in the future.
*/
On Tue, Apr 8, 2025 at 6:13 PM Tom Lane wrote:
>
> Nathan Bossart writes:
> > On Tue, Apr 08, 2025 at 09:35:24AM +0200, Hannu Krosing wrote:
> >> Changing the LO export to dumping pg_largeobject_metadata co
On Tue, Apr 8, 2025 at 6:37 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > I think we do preserve role oids
>
> Oh ... I'd been looking for mentions of "role" in
> pg_upgrade_support.c, but what I should have looked for was
> "pg_authid". So
On Tue, Apr 8, 2025 at 5:46 PM Nathan Bossart wrote:
>
> On Tue, Apr 08, 2025 at 09:35:24AM +0200, Hannu Krosing wrote:
> > On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart
> > wrote:
> >> That being said, I
> >> regularly hear about slow upgrades with many LOs
On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart wrote:
>
> On Mon, Apr 07, 2025 at 10:33:47PM +0200, Hannu Krosing wrote:
> > The obvious solution would be to handle the table
> > `pg_largeobject_metadata` the same way as we currently handle
> > `pg_largeobject `by not d
Looked like a bit illogical order on re-reading it so I want to make
clear that the pg_upgrade-like test showing 100min for 100 million LOs
is at the end of last message and the proposed solution is at the
beginning
On Tue, Apr 8, 2025 at 9:15 AM Hannu Krosing wrote:
>
> I was testing on v
I was testing on version 17
On Tue, Apr 8, 2025 at 6:52 AM Michael Paquier wrote:
>
> On Mon, Apr 07, 2025 at 05:25:32PM -0400, Tom Lane wrote:
> > What version are you testing? We did some work in that area in the
> > v17 cycle (a45c78e32).
>
> I am puzzled by the target version used here, as
Hi Hackers
## The issue
I have now met a not insignificant number of cases where pg_upgrade
performance is really bad when the database has a large number of
Large Objects.
The average time to `pg_dump --binary-upgrade --format=custom ...` a
database and then `pg_restore ...` it back is 1 minute
Just to bring this out separately :
Does anybody have any ideas why pipe commands prematurely close inside tests ?
> Re: 003-pg_dump_basic_tests has a few basic validation tests for
> correctmflag combinations. We need to write more automated tests in
> 002_pg_dump.pl but have been running into
Just to bring this out separately : Does anybody have any idea why pipe
commands close inside tests ?
Re: 003-pg_dump_basic_tests has a few basic validation tests for
correctmflag combinations. We need to write more automated tests in
002_pg_dump.pl but have been running into some issues with envi
On Thu, Feb 13, 2025 at 8:10 PM Pavel Stehule wrote:
>
> Hi
>
> čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing napsal:
>>
>> Hallo PostgreSQL Hackers,
>>
>>
>> We recently discovered an error where pgAdmin fails when stepping into
>> nested fu
Hallo PostgreSQL Hackers,
We recently discovered an error where pgAdmin fails when stepping into
nested function calls (
https://github.com/pgadmin-org/pgadmin4/issues/8443 ).
So while waiting for this to be fixed I would want to know if there
are other debugger front-ends that could be used to
On Wed, Jan 22, 2025 at 10:18 PM Robert Pang wrote:
>
> On Wed, Jan 15, 2025 at 12:05 PM Andres Freund wrote:
> >
> > If you have wal_recycle=true, this overhead will only be paid the first
> > time a
> > WAL segment is used, of course, not after recycling.
>
> Today, our pg_stat_wal view [1] do
).
--
Hannu
On Mon, Jan 20, 2025 at 12:06 PM Hannu Krosing wrote:
>
> On Fri, Jan 17, 2025 at 10:29 PM Andres Freund wrote:
> ...
> > > I see, PG once had fallocate [1] (which was reverted by [2] due to some
> > > performance regression concern). The original OSS discu
On Fri, Jan 17, 2025 at 10:29 PM Andres Freund wrote:
...
> > I see, PG once had fallocate [1] (which was reverted by [2] due to some
> > performance regression concern). The original OSS discussion was in [3].
> > The perf regression was reported in [4]. Looks like this was due to how
> > ext4 ha
On Thu, Jan 16, 2025 at 10:21 AM Ritu Bhandari
wrote:
> Could we consider adding back fallocate?
Or if not adding it back for all then maybe have a 3-value wal_init_zero :
wal_init_zero = on;
wal_init_zero = off;
wal_init_zero = fallocate;
?
Hi Tom,
Did I understand correctly that you would prefer the documentation part to
be much smaller than it is now and all current the discussion about things
that are not strictly about the pg_test_timing to be not in the docs for it
?
My current plan is to move the other discussions around timin
On Fri, Oct 4, 2024 at 4:48 PM Nathan Bossart wrote:
>
..
> Since BLCKSZ can be as low as 1024, I think 512 would be a good choice.
>
Where did you get the minimal value of 1024 from ?
I vaguely remember someone testing with 256 at some point in the past
---
Hannu
We currently do something similar with OIDs where we just keep
generating them and then testing for conflicts.
I don't think this is the best way to do it but it mostly works when
you can actually test for uniqueness, like for example in TOAST or
system tables.
Not sure this works even reasonably
On Wed, Jul 3, 2024 at 10:03 AM Tom Lane wrote:
Keep in mind also that instr_time.h does not pretend to provide
> real time --- the clock origin is arbitrary. But these results
> do give me additional confidence that gettimeofday() should be
> good to the microsecond on any remotely-modern platfo
On Tue, Jul 2, 2024 at 7:50 PM Tom Lane wrote:
>
> > Do we also need tests for this one ?
>
> Yeah, it was annoying me that we are eating the overhead of a TAP test
> for pg_test_timing and yet it covers barely a third of the code [1].
> We obviously can't expect any specific numbers out of a tes
4 ticks --
0 ( 0.0) 74.5082 74.5082 217288944
1 ( 40.0) 25.4886 99.9968 74332699
2 ( 80.0) 0. 99.9968 4
3 ( 120.0) 0. 99.9968 1
4 ( 160.0) 0. 99.9968 3
On Tue, Jul 2, 2024 at 7:31 PM Hannu Krosing wrote:
>
> Hi Tom,
>
> On various Intel CPUs I got either steps close
Hi Tom,
On various Intel CPUs I got either steps close to single nanosecond or
sometimes a little more on older ones
One specific CPU moved in in 2 tick increments while the ration to ns
was 2,1/1 or 2100 ticks per microsecond.
On Zen4 AMD the step seems to be 10 ns, even though the tick-to-ns
I agree that removing adminpack was a bit of a surprise for me as
well. At first I assumed that it was just moved into the core to
accompany the file and directory *reading* functions, until I found
the release notes mentioning that now one of the users of adminpack
does not need it and so it is dr
databases as well
On Thu, Jun 20, 2024 at 8:25 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > Or perhaps we should still also patch pg_dump to ignore the aclentries
> > which refer to roles that do not exist in the database ?
>
> I didn't want to do that before, and I
Or perhaps we should still also patch pg_dump to ignore the aclentries
which refer to roles that do not exist in the database ?
On Thu, Jun 20, 2024 at 7:41 PM Hannu Krosing wrote:
>
> Then maybe we should put a query / function in the release notes to
> clean up the existing mess.
>
role to replace it with the owner of the object if we figure out a
correct place to publish it.
---
Hannu
On Thu, Jun 20, 2024 at 5:35 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > Is there anything that could be back-patched with reasonable effort ?
>
> Afraid not.
Another thing I changed in reporting was to report <= ns instead of < ns
This was inspired by not wanting to report "zero ns" as "< 1 ns" and
easiest was to change them all to <=
On Thu, Jun 20, 2024 at 12:41 PM Hannu Krosing wrote:
>
> (resending to list a
(resending to list and other CC:s )
Hi Tom
This is my current patch which also adds running % and optionally uses
faster way to count leading zeros, though I did not see a change from
that.
It also bucketizes first 128 ns to get better overview of exact behaviour.
We may want to put reporting
Hi Tom,
Is there anything that could be back-patched with reasonable effort ?
--
Hannu
On Mon, Jun 17, 2024 at 6:37 PM Daniel Gustafsson wrote:
>
> > On 17 Jun 2024, at 16:56, Tom Lane wrote:
> > Daniel Gustafsson writes:
>
> >> I wonder if this will break any tools/scripts in prod which reli
is exactly 40 ns and I'd expect it to be the same on M1.
On Tue, Jun 18, 2024 at 5:08 PM Hannu Krosing wrote:
>
> I plan to send patch to pg_test_timing in a day or two
>
> the underlying time precision on modern linux seems to be
>
> 2 ns for some Intel CPUs
> 10 ns for
I plan to send patch to pg_test_timing in a day or two
the underlying time precision on modern linux seems to be
2 ns for some Intel CPUs
10 ns for Zen4
40 ns for ARM (Ampere)
---
Hannu
|
On Tue, Jun 18, 2024 at 7:48 AM Andrey M. Borodin
wrote:
>
>
> > On 19 Mar 2024, at 13:28, Peter Ei
to support full
"method call syntax" in general, up from one-argument case so that
SELECT function(a_thing, arg2, arg 2, ...)
could also be called as
SELECT a_thing.function(arg2, arg 2, ...)
--
Hannu
On Mon, Mar 11, 2024 at 12:55 PM Hannu Krosing wrote:
>
> On Thu, Mar 7,
On Wed, Jun 5, 2024 at 8:29 PM Tom Lane wrote:
>
> Joe Conway writes:
> > I was having a discussion regarding out-of-support branches and effort
> > to keep them building, but could not for the life of me find any actual
> > documented policy (although I distinctly remember that we do something..
Hello Everybody!
For at least last two years we have had Developers Conference
Unconference notes in PostgreSQL Wiki
https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference
https://wiki.postgresql.org/wiki/PgCon_2023_Developer_Unconference
And I know that people took notes at least at
nnu
On Sun, May 26, 2024 at 11:27 PM Daniel Gustafsson wrote:
>
> > On 26 May 2024, at 23:25, Tom Lane wrote:
> >
> > Hannu Krosing writes:
> >> Attached is a minimal patch to allow missing roles in REVOKE command
> >
> > FTR, I think this is a very b
rivileges | Policies
++---++---+--
public | revoketest | table | hannuk=arwdDxtm/hannuk | |
public | vacwatch | table || |
(2 rows)
On Sun, May 26, 2024 at 12:05 AM Hannu Krosing wrote:
>
&g
On Sat, May 25, 2024 at 4:48 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > Having an pg_init_privs entry referencing a non-existing user is
> > certainly of no practical use.
>
> Sure, that's not up for debate. What I think we're discussing
> right now
On Fri, May 24, 2024 at 10:00 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, May 24, 2024 at 2:57 PM Tom Lane wrote:
> >> Doesn't seem right to me. That will give pg_dump the wrong idea
> >> of what the initial privileges actually were, and I don't see how
> >> it can construct correct
While the 'DROP OWNED BY fails to clean out pg_init_privs grants'
issue is now fixed,we have a similar issue with REASSIGN OWNED BY that
is still there:
Tested on fresh git checkout om May 20th
test=# create user privtestuser superuser;
CREATE ROLE
test=# set role privtestuser;
SET
test=# create
On Thu, Mar 7, 2024 at 5:46 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > On Sat, Feb 10, 2024 at 12:38 AM Tom Lane wrote:
> >> Worth noting perhaps that this is actually required by the SQL
> >> standard: per spec, functions and procedures are both &quo
I could not find any explanation of the following behaviour in docs -
Our documentation for CREATE TABLE says:
CREATE TABLE also automatically creates a data type that represents
the composite type corresponding to one row of the table. Therefore,
tables cannot have the same name as any existing
Hi Tom
On Sat, Feb 10, 2024 at 12:38 AM Tom Lane wrote:
>
> "David G. Johnston" writes:
> > On Fri, Feb 9, 2024, 12:05 Deepak M wrote:
> >> Folks, When tried to create a function with the same signature as
> >> procedure it fails.
>
> > That seems like a good hint you cannot do it. Specificall
My justification for adding pl/pgsql tests as part of the immediately
available tests is that pl/pgsql itself is always enabled, so having a
no-effort way to test its performance benefits would be really helpful.
We also should have "tps-b-like as SQL function" to round up the "test
what's availabl
Thanks for the update.
I will give it another go over the weekend
Cheers,
Hannu
On Thu, Feb 1, 2024 at 7:33 PM vignesh C wrote:
> On Fri, 18 Aug 2023 at 23:04, Hannu Krosing wrote:
> >
> > I will address the comments here over this coming weekend.
>
> The patch which y
>
On Sat, Dec 2, 2023 at 4:11 PM Tom Lane wrote:
>
> Joe Conway writes:
> >> I noticed that, with the PoC patch, "json" is the only format that must be
> >> quoted. Without quotes, I see a syntax error.
In longer term we should move any specific COPY flag names and values
out of grammar and t
Hello fellow Hackers,
Does anyone know why we have decided that the wal_keep_size,
max_slot_wal_keep_size GUCs "can only be set in the postgresql.conf
file or on the server command line." [1]?
It does not seem fundamentally needed , as they are "kind of
guidance", especially the second one.
The
eira wrote:
>
> On Tue, Oct 31, 2023, at 5:09 AM, Hannu Krosing wrote:
>
> Currently we do not allow TRUNCATE of a table when any Foreign Keys
> point to that table.
>
>
> It is allowed iif you *also* truncate all tables referencing it.
>
> At the same tim
Hi
Currently we do not allow TRUNCATE of a table when any Foreign Keys
point to that table.
At the same time we do allow one to delete all rows when
session_replication_role=replica
This causes all kinds of pain when trying to copy in large amounts of
data, especially at the start of logical rep
und wrote:
>
> Hi,
>
> On 2023-09-05 21:52:18 +0200, Hannu Krosing wrote:
> > Something I also asked at this years Unconference - Do we currently
> > have Build Farm animals testing with different page sizes ?
>
> You can check that yourself as easily as anybody else.
>
> Greetings,
>
> Andres Freund
Something I also asked at this years Unconference - Do we currently
have Build Farm animals testing with different page sizes ?
I'd say that testing all sizes from 4KB up (so 4, 8, 16, 32) should be
done at least before each release if not continuously.
-- Cheers
Hannu
On Tue, Sep 5, 2023 at 4
I will address the comments here over this coming weekend.
I think that in addition to current "tpc-b like" test we could also
have more modern "tpc-c like" and "tpc-h like" tests
And why not any other "* -like" from the rest of TPC-*, YCSP, sysbench, ... :)
though maybe not as part of pg_bench
I would look at how Babelfish DB did it when adding SQL Server compatibility
https://babelfishpg.org/ and https://github.com/babelfish-for-postgresql/
another source to inspect could be
https://github.com/IvorySQL/IvorySQL for "oracle compatible
PostgreSQL"
On Tue, Aug 1, 2023 at 10:07 PM Jonah
On Wed, Jul 26, 2023 at 9:54 PM Matthias van de Meent
wrote:
>
> Then you ignore the max_wal_size GUC as PostgreSQL so often already
> does. At least, it doesn't do what I expect it to do at face value -
> limit the size of the WAL directory to the given size.
That would require stopping any new
Starting from increments checkpoint is approaching the problem from
the wrong end.
What you actually want is Atomic Disk Writes which will allow turning
off full_page_writes .
Without this you really can not do incremental checkpoints efficiently
as checkpoints are currently what is used to deter
Thanks a lot Mark,
I will take a look at this and get back to you if I find anything unclear
---
Hannu
On Tue, Jul 4, 2023 at 10:14 PM Mark Dilger
wrote:
>
> Hackers,
>
> Over in [1], Hannu Krosing asked me to create and post several Table Access
> Methods for testing/example
At PgCon 2023 in Ottawa we had an Unconference session on Table Access
Methods [1]
One thing that was briefly mentioned (but is missing from the notes)
is need to have a sample API client in contrib/ , both for having a
2nd user for API to make it more likely that non-heap AMs are doable
and also
caches.
On Thu, Jun 15, 2023 at 11:04 AM Hannu Krosing wrote:
>
> On Thu, Jun 15, 2023 at 10:41 AM James Addison wrote:
> >
> > This is making me wonder about other performance/scalability areas
> > that might not have been considered due to focus on the details of the
&g
On Thu, Jun 15, 2023 at 10:41 AM James Addison wrote:
>
> This is making me wonder about other performance/scalability areas
> that might not have been considered due to focus on the details of the
> existing codebase, but I'll save that for another thread and will try
> to learn more first.
A gr
On Thu, Jun 15, 2023 at 9:12 AM Konstantin Knizhnik wrote:
> There are three different but related directions of improving current
> Postgres:
> 1. Replacing processes with threads
Here we could likely start with making parallel query multi-threaded.
This would also remove the big blocker for
On Tue, Jun 13, 2023 at 9:55 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 13 Jun 2023 09:55:36 +0300, Konstantin Knizhnik
> wrote in
> > Postgres backend is "thick" not because of large number of local
> > variables.
> > It is because of local caches: catalog cache, relation cache, prepared
> > state
On Mon, Jun 5, 2023 at 4:52 PM Heikki Linnakangas wrote:
>
> If there are no major objections, I'm going to update the developer FAQ,
> removing the excuses there for why we don't use threads [1].
I think it is not wise to start the wholesale removal of the objections there.
But I think it is wo
I discovered this thread from a Twitter post "PostgreSQL will finally
be rewritten in Rust" :)
On Mon, Jun 5, 2023 at 5:18 PM Tom Lane wrote:
>
> Heikki Linnakangas writes:
> > I spoke with some folks at PGCon about making PostgreSQL multi-threaded,
> > so that the whole server runs in a single
On Thu, Jun 8, 2023 at 4:56 PM Robert Haas wrote:
>
> On Thu, Jun 8, 2023 at 8:44 AM Hannu Krosing wrote:
> > > That sounds like a bad idea, dynamic shared memory is more expensive
> > > to maintain than our static shared memory systems, not in the least
> > >
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:
> >
> > On Wed, Jun 7, 2023 at 11:37 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2023-06-05 13:40:13 -0400, Jonat
I guess that COPY will still be slower than generating the data
server-side ( --init-steps=...G... ) ?
What I'd really like to see is providing all the pgbench functions
also on the server. Specifically the various random(...) functions -
random_exponential(...), random_gaussian(...), random_zipf
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, Jonathan S. Katz wrote:
> > > 2. While I wouldn't want to necessarily discourage a moonshot
On Thu, Jun 8, 2023 at 12:09 AM Andres Freund wrote:
...
> We could e.g. eventually decide that we
> don't support parallel query without threading support - which would allow us
> to get rid of a very significant amount of code and runtime overhead.
Here I was hoping to go in the opposite direc
1 - 100 of 168 matches
Mail list logo
