On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
> In v16 and later, the following fails:
>
> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
> COPY boom FROM STDIN;
> ERROR: value too long for type character varying(5)
>
> In Po
ot cool if
something that worked without an error in v15 starts to fail later on.
Yours,
Laurenz Albe
set "local_update_limit" when the
table has shrunk enough. Why not perform that task during vacuum truncation?
If vacuum truncation has taken place, check if the table size is no bigger
than "local_update_limit" * (1 + "autovacuum_vacuum_scale_factor"), and if
it is
think that index bloat is a show stopper
these days, when we have REINDEX CONCURRENTLY, so I am not worried.
Yours,
Laurenz Albe
On Mon, 2023-09-18 at 12:22 -0400, Robert Haas wrote:
> On Tue, Sep 5, 2023 at 11:15 PM Laurenz Albe wrote:
> > I don't think that is a good comparison. While most people probably
> > never need to touch "local_update_limit", "work_mem" is something everyb
he main
* grammar, rather than here, will still be thrown.
"escontext" is an ErrorSaveContext node, and it is the parser failing.
Not sure if we can do anything about that or if it is worth the effort.
Perhaps the documentation could reflect the implementation.
Yours,
Laurenz Albe
artitions are "normal tables".
Agreed, there are differences between partitions and normal tables.
And this is not the place in the documentation where we would like to
get into detail about the differences.
Attached is the next version of my patch.
Yours,
Laurenz Albe
From 33ef30888b5f5
pack.
I think this is useful.
To alleviate your concerns, perhaps it would help to describe the use case
and ideas for a good setting in the documentation.
Yours,
Laurenz Albe
On Thu, 2023-08-24 at 18:23 +0200, Matthias van de Meent wrote:
> On Wed, 19 Jul 2023 at 15:13, Thom Brown wrote:
> >
> > On Wed, 19 Jul 2023, 13:58 Laurenz Albe, wrote:
> > > I agree that the name "max_local_update" could be improved.
> > > Per
On Thu, 2023-08-17 at 09:37 +0900, Michael Paquier wrote:
> I have just noticed that we do not have a CF entry for this proposal,
> so I have added one with Laurenz as author:
> https://commitfest.postgresql.org/44/4504/
I have changed the author to Fujii Masao.
Yours,
Laurenz Albe
On Sat, 2023-07-08 at 08:11 +0200, Kim Johan Andersson wrote:
> On 07-07-2023 13:20, Laurenz Albe wrote:
> > I wrote:
> > > You implement both "SupportRequestIndexCondition" and
> > > "SupportRequestSimplify",
> > > but when I e
uming */
boolvacuum_truncate;/* enables vacuum to truncate a relation */
+ int max_local_update; /* Updates to pages after this block must
go through the VM */
} StdRdOptions;
#define HEAP_MIN_FILLFACTOR10
In the comment, it should be FSM, not VM, right?
Other than that, I see nothing wrong.
Yours,
Laurenz Albe
But this was reverted in 2535c74b1a6190cc42e13f6b6b55d94bff4b7dd6.
Yours,
Laurenz Albe
\ev or \ef, right?
Yours,
Laurenz Albe
quot;, for example
Index Cond (expr >= lower(range) AND expr < upper(range)).
Yours,
Laurenz Albe
ature to be
> useful.
Right, I agree. A GUC/storage parameter like "update_strategy"
that is an enum (try-hot | first-page | ...).
To preserve BRIN indexes or CLUSTERed tables, there could be an additional
"insert_strategy", but that would somehow have to be tied to a certain
index. I think that is out of scope for this effort.
Yours,
Laurenz Albe
2 rows)
SELECT * FROM tx WHERE t <@ textrange('a', 'd');
ERROR: could not determine which collation to use for string comparison
HINT: Use the COLLATE clause to set the collation explicitly.
The replacement operators are wrong; it should be ~>=~ and ~<~ .
Also, there should be no error message.
The result should be 'a', 'c' and 'ch'.
Yours,
Laurenz Albe
CONTAINED_BY_RANGE ||
req->funcid == F_RANGE_CONTAINS_ELEM);
if (req->funcid == F_ELEM_CONTAINED_BY_RANGE)
{
[...]
}
else if (req->funcid == F_RANGE_CONTAINS_ELEM)
{
[...]
}
Yours,
Laurenz Albe
ubject should really be "Allow forcing UPDATEs off the same page".
I've been thinking about the same thing - an option that changes the update
strategy to always use the lowest block with enough free space.
That would allow to consolidate bloated tables with no down time.
Yours,
Laurenz Albe
On Sun, 2023-07-02 at 20:13 +0200, Tomas Vondra wrote:
> FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
> the report!
Thanks, and sorry for being pushy.
Yours,
Laurenz Albe
happy to let you take it -- got lots of other stuff on my plate.
>
> OK, will do.
It would be cool if we could get that into the next minor release in August.
Yours,
Laurenz Albe
_test/pg_upgrade_testing/postgres_14/new_pg
> 11224524 /home/test/pradeep_test/pg_upgrade_testing/postgres_11.4/master
> 41952 /home/test/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
That looks fine. The files exist only once, and the 41MB that only exist in
the new data directory are catalog data and other stuff that is different
on the new cluster.
Yours,
Laurenz Albe
ing in a significant increase in the new
> cluster's size.
Please provide some numbers, ideally
du -sk
Yours,
Laurenz Albe
ding jit=off for all but analytic workloads.
Yours,
Laurenz Albe
; public | parttest_10_7 | fdw_node5
> public | parttest_10_9 | fdw_node6
> (5 rows)
>
> (Muffled sound of small patch hatching) aha:
>
> postgres=# SELECT * FROM parttest;
> ERROR: user mapping not found for user "postgres", server "fdw_node5"
+1
Yours,
Laurenz Albe
errmsg("Damn1! Update were done
> in a non-volatile function")));
I think it is project policy to start error messages with a lower case
character.
Yours,
Laurenz Albe
t;fullsort_state = NULL;
}
if (node->prefixsort_state != NULL)
{
- tuplesort_reset(node->prefixsort_state);
+ tuplesort_end(node->prefixsort_state);
node->prefixsort_state = NULL;
}
The original comment hints that this might mot be the correct thing to do...
Yours,
Laurenz Albe
tests show that it is calculated
> at execution time.
Ah, ok, then sorry for the noise. I misread the code then.
Yours,
Laurenz Albe
nal author, I'd say that that sounds reasonable, particularly
in case #1. If the postmaster dies, we are going to die too, so it
probably doesn't matter much. But I think an error is certainly also
correct in that case.
Yours,
Laurenz Albe
n explicitly.
>
> We have never seen this before. Could this be a bug?
Impossible to say without a way to reproduce.
Yours,
Laurenz Albe
d be faily trivial, if not very useful.
At a quick glance, it looks like you resolve "timezone" at the time
the query is parsed. Shouldn't the resolution happen at query
execution time?
Yours,
Laurenz Albe
nd
> > this feature useful.
>
> Please see attached the patch that introduces this new feature.
Can you explain why *you* would find this feature useful?
Yours,
Laurenz Albe
iew and define the order of fields if we need
> to display the fields of table in a order of our demand, it is not a
> good way.
But PostgreSQL tables are not spreadsheets. When, except in the display of
the result of interactive queries, would the order matter?
Yours,
Laurenz Albe
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
I found two typos.
Yours,
Laurenz Albe
diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index faecae7c42..7dad0b8550 100644
--- a/doc/src/sgml/release
g │ pg_get_viewdef │ text │ text, boolean
│ func
(17 rows)
A server function can be conveniently called from any client code.
Yours,
Laurenz Albe
of what isn't normally part of "psql"
output.
"okbob" should be "Pavel Stehule".
Yours,
Laurenz Albe
;p','u','x'))
> > WHERE c.oid = '21949943' AND c.oid = i.indrelid AND i.indexrelid = c2.oid
> > ORDER BY i.indisprimary DESC, c2.relname;
> > -- **
>
> This looks little bit strange
>
> What about /* comments
>
> Like
>
> /*** Query /
>
> Or just
>
> Query
+1 for either of Pavel's suggestions.
Yours,
Laurenz Albe
sing statement_timeout and hot_standby_feedback = on
on the standby instead.
That should have pretty much the same effect, and it is measured in
time and not in the number of transactions.
Yours,
Laurenz Albe
t]
>
> +1 for removing.
I am not against this in principle, but I know that there are people using
this parameter; see the discussion linked in
https://postgr.es/m/e1jkzxe-0006dw...@gemulon.postgresql.org
I can't say if they have a good use case for that parameter or not.
Yours,
Laurenz Albe
ention to that when creating a
cluster, so having a locale-agnostic collation is often better than
inheriting whatever default happened to be set in your shell.
For example, the Debian/Ubuntu binary packages create a cluster when
you install the server package, and most people just go on using that.
Yours,
Laurenz Albe
nd it might well be a bug lurking in the FDW part of the
optimizer code. It is not FDW specific, since I discovered it with
oracle_fdw and could reproduce it with postgres_fdw.
I was aware that it is awkward to add a test to a contrib module, but
I thought that I should add a test that exercises the new code path.
But I am fine without the postgres_fdw test.
Yours,
Laurenz Albe
And here is v10, which includes tab completion for the new option.
Yours,
Laurenz Albe
From dfe6d36d79c74fba7bf70b990fdada166d012ff4 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 23 Mar 2023 19:28:49 +0100
Subject: [PATCH] Add EXPLAIN option GENERIC_PLAN
This allows EXPLAIN to generate
r key2=$1
I did that, with a different comment.
> The test involving postgres_fdw is still necessary to exercise the new
> EXEC_FLAG_EXPLAIN_GENERIC code path, but needs to be moved elsewhere,
> probably src/test/modules/.
Tests for postgres_fdw are in contrib/postgres_fdw/sql/postgres_fd
but
that can be expected).
I checked the documentation, tested "pg_dump" support, everything fine.
I'll mark it as "ready for committer".
Yours,
Laurenz Albe
rmats? Maybe there are people using special
> delimiters/terminators and they need them to be treated a certain way
> during comparisons?
I regularly see complaints about the sort order; recently this one:
https://postgr.es/m/cafcrh--xt-j8awoavhb216kom6tqnap35ttveqqs5bhh7gm...@mail.gmail.com
So being able to influence the sort order is useful.
Yours,
Laurenz Albe
> Right, that would be an initdb option. Is that too many initdb options
> then? It would be easy to add, if we think it's worth it.
An alternative would be to document that you can drop "template1" and
create it again using the ICU collation rules you need.
But I'd prefer an "initdb" option.
Yours,
Laurenz Albe
It adds some value by being simpler and uniform across all platforms.
I'll mark the patch as "ready for committer".
Yours,
Laurenz Albe
ons, as far as I know.
Yours,
Laurenz Albe
o with the default choice of ICU, you should configure your
package manager not to upgrade the ICU library.
Yours,
Laurenz Albe
tabase
with "ICU_LOCALE x", the rules are not copied over.
I don't know if that is intended or not, but it surprises me.
Should that be a WARNING? Or, since creating a database with a collation
that does not exist in "template0" doesn't make much sense (or does it?),
is there a way to forbid that?
Yours,
Laurenz Albe
On Mon, 2023-02-13 at 16:33 -0800, Andres Freund wrote:
> On 2023-02-05 18:24:03 +0100, Laurenz Albe wrote:
> > Anyway, attached is v7 that tries to do it that way.
>
> This consistently fails on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42
can change in the
meantime. Think of prepared statements using a generic plan.
Yours,
Laurenz Albe
ag EXEC_FLAG_EXPLAIN_GENERIC.
To avoid having to change all the places that check EXEC_FLAG_EXPLAIN_ONLY
to also check for the new flag, I decided that the new flag can only be
used as "add-on" to EXEC_FLAG_EXPLAIN_ONLY.
Yours,
Laurenz Albe
From cd0b5a1a4f301bb7fad9088d5763989f5dde4636
On Sat, 2023-02-04 at 14:41 +0100, Daniel Verite wrote:
> Laurenz Albe wrote:
>
> > Cool so far. Now I created a database with that locale:
> >
> > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone
> > LOCALE "de_AT.utf8" TE
On Fri, 2023-02-03 at 09:44 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I played around with it, and I ran into a problem with partitions that
> > are foreign tables:
> > ...
> > EXPLAIN (GENERIC_PLAN) SELECT * FROM looppart WHERE key = $1;
> > ERROR
On Tue, 2023-01-31 at 13:49 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > [ 0001-Add-EXPLAIN-option-GENERIC_PLAN.v4.patch ]
>
> I took a closer look at this patch, and didn't like the implementation
> much. You're not matching the behavior of PREPARE at all:
> What do you think of "--load-via-partition-root=on/off/auto", where
> auto means "not with hash partitions" or the like?
That's perhaps the best way. So users who know that their hash
partitions won't change and want the small speed benefit can have it.
Yours,
Laurenz Albe
e fault of this patch that the collation isn't there,
but I think it is surprising. What good is a database collation that does not
exist in the database?
What might be the fault of this patch, however, is that "daticurules" is not
set in "pg_database". Looking at the code, that column seems to be copied
from the template database, but cannot be overridden.
Perhaps this only needs more documentation, but I am confused.
Yours,
Laurenz Albe
he existence of pg_xact_status, so I suspect that it
is not a widely known and used feature. After reading the documentation,
I'd say that anybody who uses it will want it to give a reliable answer.
So I'd agree that it is better to make it more expensive, but live up to
its promise.
Yours,
Laurenz Albe
On Wed, 2023-01-25 at 16:26 +1300, David Rowley wrote:
> On Wed, 18 Jan 2023 at 22:15, Laurenz Albe wrote:
> > Attached is a new version of my patch that tries to improve the wording.
>
> I had a look at this and agree that we should adjust the paragraph in
> question if peo
On Tue, 2023-01-24 at 01:38 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > We throw an error if the expression in a CREATE INDEX statement is not
> > IMMUTABLE.
> > But while the documentation notes that expressions in CHECK constraints are
> > not
> > to be
t wouldn't catch all abuse,
but it would be better than nothing.
There is of course the worry of breaking upgrade for unsafe constraints, but is
there any other reason not to enforce immutability?
Yours,
Laurenz Albe
few more TB disk storage.
Yours,
Laurenz Albe
.com/en/streaming-replication-conflicts-in-postgresql/
Yours,
Laurenz Albe
On Thu, 2023-01-19 at 15:56 -0500, Bruce Momjian wrote:
> On Thu, Jan 19, 2023 at 01:50:05PM +0100, Laurenz Albe wrote:
> > On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> > > Is it possible to document when partition table statistics helps?
> >
> > I think
On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> > > I seem to recall that the original idea was to report the timestamp
> > > of the commit/abort record we are stopping at. Maybe my me
On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> Is it possible to document when partition table statistics helps?
I think it would be difficult to come up with an exhaustive list.
Yours,
Laurenz Albe
its
> > partitions changes significantly.
> >
>
> "partitions are normal tables" was techically wrong, as partitions can
> also be partitioned.
I am fine with your tweaks. I think this is good to go.
Yours,
Laurenz Albe
this thread[1]. It doesn't take
an exotic query.
Attached is a new version of my patch that tries to improve the wording.
Yours,
Laurenz Albe
[1]: https://postgr.es/m/3df5c68b-13aa-53d0-c0ec-ed98e6972e2e%40postgrespro.ru
From 53da8083556364490d42077492e608152f9ae02e Mon Sep 17 00:00:00 20
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
> > > So, the timestamp displayed in the log message is certainly wrong.
>
> > If recovery stops at a WAL record that has no timest
ecovery stop time. I think we should show the recovery stop time
only if time was the target, as in the attached patch.
Yours,
Laurenz Albe
From 622e52bbd652fc8872448e46c3ca0bc78dd847fe Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 17 Jan 2023 10:38:40 +0100
Subject: [PATCH] Don't show
declared here
> 2909 | bool generic_plan;
> | ^~~~
Thanks for checking. The variable should indeed be initialized, although
my compiler didn't complain.
Attached is a fixed version.
Yours,
Laurenz Albe
From baf60d9480d8022866d1ed77b00c7b8506f97f70 Mon Sep 17
On Tue, 2022-12-06 at 10:17 -0800, Andres Freund wrote:
> On 2022-10-29 10:35:26 +0200, Laurenz Albe wrote:
> > > > Here is a patch that
> > > > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> This fails to build the docs:
>
> https://cirrus-c
On Wed, 2022-11-30 at 10:09 +0100, Vik Fearing wrote:
> On 11/29/22 17:29, Laurenz Albe wrote:
> > On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> > > I disagree. A user does not need to know that a table is partitionned,
> > > and if the user wants a unique c
y without thinking too hard about it,
only to discover later that dropping old partitions has become a problem,
I would not be too happy either.
Yours,
Laurenz Albe
e. On the other hand, it might happen that after this, people start
worrying about normal autovacuum runs because they occasionally experience
a table age autovacuum that is much heavier than the other ones. And
they can no longer tell the reason, because it doesn't show up anywhere.
Yours,
Laurenz Albe
aparound cutoffs were chosen because they're
> easy to understand and remember, which is fairly arbitrary.
The target is a table that receives no DML at all, right?
I think that is a good idea.
Wouldn't it make sense to trigger that at *half* "autovacuum_freeze_max_age"?
Yours,
Laurenz Albe
already in that status.
Yours,
Laurenz Albe
sible use-case where this'd be a
> difficult change to deal with, I concur that we don't need to
> deprecate it ahead of time.
Since I am the only one that seems to worry, I'll shut up. You are probably
right that it the feature won't be missed by many users.
Yours,
Laurenz Albe
sactions
> + will have virtualxids but NULL
> + transactionids, while read-write transactions
> + will have both as non-NULL.
> +
Perhaps the following will be prettier than "have both as non-NULL":
..., while both columns will be set in read-write transactions.
Yours,
Laurenz Albe
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyon
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chan
meter, but I don't think that it is a good idea to deviate from our
usual standard of deprecating a feature for about five years before
actually removing it.
Yours,
Laurenz Albe
On Thu, 2022-11-10 at 12:17 +0100, Alvaro Herrera wrote:
> On 2022-Nov-10, Laurenz Albe wrote:
> > On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> > > > > - If AND CHAIN is specified, a new
> > > > > transaction is
> > > >
On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
> > Some comments:
> >
>
> > > --- a/doc/src/sgml/ref/release_savepoint.sgml
> > > +++ b/doc/src/sgml/ref/release_savepoint.sgml
> >
ctions. How is that?
It is better. Did you take my suggestions from [1] into account in your
latest cumulative patch in [2]? Otherwise, it will be difficult to
integrate both.
Yours,
Laurenz Albe
[1]:
https://postgr.es/m/3603e6e85544daa5300c7106c31bc52673711cd0.camel%40cybertec.at
[2]: https://postgr.es/m/Y2nP04/3BHQOviVB%40momjian.us
On Mon, 2022-11-07 at 23:04 +0100, Laurenz Albe wrote:
> On Sat, 2022-11-05 at 10:08 +, Simon Riggs wrote:
> > Agreed; new compilation patch attached, including mine and then
> > Robert's suggested rewordings.
>
> Thanks. There is clearly a lot of usefule info
Row-level read and write locks are recorded directly in locked
> +rows and can be inspected using the
> +extension. Row-level read locks might also require the assignment
> +of multixact IDs (mxid). Mxids are recorded in
> +the pg_multixact directory.
"are recorded directly in *the* locked rows"
I think the mention of multixacts should link to
. Again, I would not
specifically mention the directory, since it is already described in
"storage.sgml", but I have no strong optinion there.
> +
> +
> + Subtransactions
> +The word subtransaction is often abbreviated as
> +subxact.
I'd use , not .
> +If a subtransaction is assigned a non-virtual transaction ID,
> +its transaction ID is referred to as a subxid.
Again, I would use , since we don't "subxid"
elsewhere.
+ Up to
+64 open subxids are cached in shared memory for each backend; after
+that point, the overhead increases significantly since we must look
+up subxid entries in pg_subtrans.
Comma before "since". Perhaps you should mention that this means disk I/O.
Yours,
Laurenz Albe
eak
configured with "autovacuum_vacuum_cost_delay". Reduce that parameter for more
autovacuum speed.
Yours,
Laurenz Albe
gger. Is this just an incremental patch? If yes, it would
be nice to have a "grand total" patch, so that I can read it all
in one go.
Yours,
Laurenz Albe
0003 go in, but it currently depends on 0001, which
I am not so sure about.
I understand that you did that so that "explain_regress" can turn off BUFFERS
and there is no extra churn in the regression tests.
Still, it would be a shame if resistance against "explain_regress" would
be a show-stopper for 0003.
If I could get my way, I'd want two separate patches: first, one to turn
BUFFERS on, and second one for "explain_regress" with its current functionality
on top of that.
Yours,
Laurenz Albe
On Tue, 2022-10-25 at 19:03 +0800, Julien Rouhaud wrote:
> On Tue, Oct 25, 2022 at 11:08:27AM +0200, Laurenz Albe wrote:
> > Here is a patch that
> > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> I only have a quick look at the patch for now. Any reason why yo
o query ID, no Heap Fetches, no Sort details, ...
Why not add this functionality to the GUC?
0005 suppresses "rows removed by filter", but how is that machine dependent?
> BTW, I think it may be that the GUC should be marked PGDLLIMPORT ?
I think it is project policy to apply this mark wherever it is needed. Do you
think
that third-party extensions might need to use this in C code?
Yours,
Laurenz Albe
have to go to great lengths
> trying to "unjumble" such queries, so having a way to easily get the answer
> for
> a generic plan would be great.
Thanks for the suggestions and the encouragement. Here is a patch that
implements it with an EXPLAIN option named GENERIC_PLAN.
Yours,
hould not be encouraged.
Anybody who knows enough about PostgreSQL to be sure that what they are
doing is correct should be smart enough to know how to edit the copied file.
Yours,
Laurenz Albe
as a full-fledged EXPLAIN (ANALYZE, BUFFERS),
but it can definitely be helpful.
I tied that behavior to the setting of "plan_cache_mode" where you
are guaranteed to get a generic plan; I couldn't think of a better way.
Yours,
Laurenz Albe
From 2bc91581acd478d4648176b58745cadb835d5fbc
een, the optimizer always used the statistics of the partitions.
Yours,
Laurenz Albe
From 5209f228f09e52780535edacfee5f7efd2c25081 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 5 Oct 2022 10:31:47 +0200
Subject: [PATCH] Improve autovacuum doc on partitioned tables
The documentation mention
over time, the use of the older serial
> mechanisms would go away.
I think that would be great.
That might generate some confusion among users who follow old tutorials
and are surprised that the eventual table definition differs, but I'd say
that is a good thing.
Yours,
Laurenz Albe
say that this is a pretty obvious case of pilot error.
Yours,
Laurenz Albe
other thread?
For reference: that was
https://postgr.es/m/f6a491b32cb44bb5daaafec835364f7149348fa1.ca...@cybertec.at
Yours,
Laurenz Albe
201 - 300 of 735 matches
Mail list logo
