Doc: use true|false rather than on|off for "failover" option
The CREATE SUBSCRIPTION documentation mentions "false" is the default
option, so let's use true|false rather than on|off in the text which
talks about this option in the ALTER SUBSCRIPTION page.
The other boolean options mentioned in
Fix some inconsistencies in EXPLAIN output
06286709e added a SERIALIZE option to EXPLAIN which included showing the
amount of kilobytes serialized. The calculation to convert bytes into
kilobytes wasn't consistent with how that's done in the rest of EXPLAIN.
Traditionally we round up to the
Fix incorrect year in some copyright notices added this year
A few patches that were written <= 2023 and committed in 2024 still
contained 2023 copyright year. Fix that.
Discussion:
https://postgr.es/m/caaphdvr5egyw3fmhbag-uq2p_aizwco1zjs6vbq18kqn64-...@mail.gmail.com
Branch
--
master
Revert "Temporarily install debugging in partition_prune test"
1db689715 added debugging output to the partition_prune regression test
to help us figure out why buildfarm member Parula was occasionally
failing.
We've not seen any failures in around 4 weeks and the best guess as to
what the
Fix query pullup issue with WindowClause runCondition
94985c210 added code to detect when WindowFuncs were monotonic and
allowed additional quals to be "pushed down" into the subquery to be
used as WindowClause runConditions in order to short-circuit execution
in nodeWindowAgg.c.
The Node
Fix an assortment of typos
Author: Alexander Lakhin
Discussion: https://postgr.es/m/ae9f2fcb-4b24-5bb0-4240-efbbbd944...@gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a42fc1c903b54ba94374e5e0c08905b9a1479f19
Modified Files
--
On Wed, 1 May 2024 at 17:02, Tatsuo Ishii wrote:
> > Bug: #18170
>
> Maybe you are talking about BUG #18305:
> Unexpected error: "WindowFunc not found in subplan target lists" ?
Unsure what happened there, but yes, you're right. That should be
#18305 and [1].
I believe I just copied and pasted
Fix typos and incorrect type in read_stream.c
max_ios should be int rather than int16, otherwise there's not much
point in doing:
max_ios = Min(max_ios, PG_INT16_MAX);
Discussion:
https://postgr.es/m/caaphdvr9un-xpdr_+afdogm38o2k8spfohimqz838ggutgy...@mail.gmail.com
Branch
--
master
Disable run condition optimization for some WindowFuncs
94985c210 added code to detect when WindowFuncs were monotonic and
allowed additional quals to be "pushed down" into the subquery to be
used as WindowClause runConditions in order to short-circuit execution
in nodeWindowAgg.c.
The Node
Disable run condition optimization for some WindowFuncs
94985c210 added code to detect when WindowFuncs were monotonic and
allowed additional quals to be "pushed down" into the subquery to be
used as WindowClause runConditions in order to short-circuit execution
in nodeWindowAgg.c.
The Node
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot,
On Tue, 30 Apr 2024 at 14:14, Tom Lane wrote:
> Yeah, the affected buildfarm members seem still not happy.
Isn't your latest fix adding COLLATE "C" to the wrong test?
Crake is failing with [1]:
---
/home/andrew/bf/root/HEAD/pgsql/src/test/modules/test_pg_dump/expected/test_pg_dump.out
On Tue, 30 Apr 2024 at 12:23, Tom Lane wrote:
>
> Fix test case from b0c5b215d.
Still failing for me and [1].
Maybe:
SELECT pg_describe_object(classid,objid,objsubid) COLLATE "C" AS obj,
Gets me the results in the expected order.
David
[1]
Fix duplicated consecutive words in comments
Also, fix a comment incorrectly referencing the "streaming read API".
This was renamed to "read stream" shortly before being committed.
Discussion:
https://postgr.es/m/caaphdvq-2zdqytm_hf3rmvf0qg5ps9jtfaj5qtc9xh9pwvw...@mail.gmail.com
Branch
--
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Doc: document cases where queryid is stable
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Update mmgr's README to mention BumpContext
Oversight in 29f6a959c.
In passing, since we now have 4 memory context types to choose from,
provide a brief overview of the specialities of each memory context
type.
Reported-by: Amul Sul
Author: Amul Sul, David Rowley
Discussion:
https://postgr.es
Push dedicated BumpBlocks to the tail of the blocks list
BumpContext relies on using the head block from its 'blocks' field to
use as the current block to allocate new chunks to. When we receive an
allocation request larger than allocChunkLimit, we place these chunks on
a new dedicated block
Improve test coverage in bump.c
There were no callers of BumpAllocLarge() in the regression tests, so
here we add a sort with a tuple large enough to use that path in bump.c.
Also, BumpStats() wasn't being called, so add a test to sysviews.sql to
call pg_backend_memory_contexts() while a bump
Fix recently introduced typo in code comment
Reported-by: Richard Guo
Discussion:
https://postgr.es/m/cambws49kaszusj7-0sblve9+ukz0rcqmemm3nvytc1yvs8s...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/b9ecefecc7aaad117e0255b56b759f524f0f4363
.
The same is true for CHECK constraints as those must also match between
arent partitioned tables and their partitions.
Author: Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cambws4930gqszmjr7aanzeapdy61gcg6z8dt-kaeyd0sywk...@mail.gmail.com
Branch
--
master
Details
---
https
Fixup various StringInfo function usages
This adjusts various appendStringInfo* function calls to use a more
appropriate and efficient function with the same behavior. For example,
use appendStringInfoChar() when appending a single character rather than
appendStringInfo() and
On Wed, 10 Apr 2024 at 00:05, Peter Eisentraut wrote:
> This patch introduces in bump.c the macro BumpBlockIsValid(), but it's
> not used anywhere. Can we remove it?
I've just pushed a patch to remove it.
Was that spotted by eagle eyes or tooling?
David
Remove unused BumpBlockIsValid macro
The bump allocator was recently added in 29f6a959c. Our other
allocators have a similar macro to this, but seemingly the version of
the macro for those allocators is only used in places where the chunk
header is decoded. Since the bump allocator has no chunk
Doc: use "an SQL" instead of "a SQL"
Although which is correct depends entirely on whether you pronounce SQL
as "ess-que-ell" or "sequel", we have standardized on the former in our
user-facing documentation, so use the correct article according to that
pronunciation.
Discussion:
Fix incorrect KeeperBlock macro in bump.c
The macro was missing a MAXALIGN around the sizeof(BumpContext) which
would cause problems detecting the keeper block on 32-bit systems that
have a MAXALIGN value of 8.
Thank you to Andres Freund, Tomas Vondra and Tom Lane for investigating
and testing.
fit more tuples in work_mem
before spilling to disk, or perform an in-memory sort touching fewer
cacheline.
Author: David Rowley
Reviewed-by: Nathan Bossart
Reviewed-by: Matthias van de Meent
Reviewed-by: Tomas Vondra
Reviewed-by: John Naylor
Discussion:
https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp
an unsupported
operation could result in a segfault.
A follow-on commit will implement the first user of bump.
Author: David Rowley
Reviewed-by: Nathan Bossart
Reviewed-by: Matthias van de Meent
Reviewed-by: Tomas Vondra
Reviewed-by: John Naylor
Discussion:
https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp
bit which frees up 8 slots for future memory context
types.
In passing, adjust the enum names in MemoryContextMethodID to make it
more clear which ones can be used and which ones are reserved.
Author: Matthias van de Meent, David Rowley
Discussion:
https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp
are; outputting large tuples with SELECT or COPY TO STDOUT and
pg_basebackup.
Author: Melih Mutlu
Reviewed-by: Heikki Linnakangas
Reviewed-by: Jelte Fennema-Nio
Reviewed-by: David Rowley
Reviewed-by: Ranier Vilela
Reviewed-by: Andres Freund
Discussion:
https://postgr.es/m/cagpvpcr15nosj0f6xe
Secondary refactor of heap scanning functions
Similar to 44086b097, refactor heap scanning functions to be more
suitable for the read stream API.
Author: Melanie Plageman
Discussion:
https://postgr.es/m/CAAKRu_YtXJiYKQvb5JsA2SkwrsizYLugs4sSOZh3EAjKUg=g...@mail.gmail.com
Branch
--
master
Preliminary refactor of heap scanning functions
To allow the use of the read stream API added in b5a9b18cd for
sequential scans on heap tables, here we make some adjustments to make
that change less invasive and perhaps make the code easier to follow in
the process.
Here heapgetpage() gets
Don't adjust ressortgroupref in generate_setop_child_grouplist()
This is already done inside assignSortGroupRef(), therefore is
redundant.
Oversight from 66c0185a3.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/3703023.1711654...@sss.pgh.pa.us
Branch
--
master
Details
---
On Wed, 3 Apr 2024 at 09:42, Alexander Korotkov wrote:
> I'm trying to figure out if this failure could be related to this commit...
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae=2024-04-02%2020%3A24%3A55
Yeah, I think it is.
The problem is that in WaitLSNSetLatches()
Don't zero tuple_fraction when planning UNIONs with ORDER BYs
Since 66c0185a3, the planner is able to use Merge Append -> Unique to
implement UNION queries and each subquery is prompted to produce Paths
correctly sorted by the UNION's targetlist.
Here we remove some now redundant code which was
Fix assert failure when planning setop subqueries with CTEs
66c0185a3 adjusted the UNION planner to request that union child queries
produce Paths correctly ordered to implement the UNION by way of
MergeAppend followed by Unique. The code there made a bad assumption
that if the
Fix unstable aggregate regression test
Buildfarm member avocet has shown a plan change by switching the
finalize aggregate stage to use a GroupAggregate rather than a
HashAggregate. This is consistent with autovacuum having triggered on
the table, per analysis by Alexander Lakhin.
Fix this by
Fix unstable aggregate regression test
Buildfarm member avocet has shown a plan change by switching the
finalize aggregate stage to use a GroupAggregate rather than a
HashAggregate. This is consistent with autovacuum having triggered on
the table, per analysis by Alexander Lakhin.
Fix this by
On Thu, 21 Mar 2024 at 14:10, Masahiko Sawada wrote:
>
> Add TIDStore, to store sets of TIDs (ItemPointerData) efficiently.
> src/backend/access/common/tidstore.c | 463 +
I was looking at this code and I saw the following:
/* choose the maxBlockSize to be no
On Mon, 25 Mar 2024 at 13:07, Alexander Korotkov
wrote:
> reindexdb: Add the index-level REINDEX with multiple jobs
This seems to cause a new compiler warning:
reindexdb.c: In function ‘reindex_one_database’:
reindexdb.c:437:45: warning: ‘indices_tables_cell’ may be used
uninitialized
of the unioned rows as
cheap startup plans can be used.
Author: David Rowley
Reviewed-by: Richard Guo, Andy Fan
Discussion:
https://postgr.es/m/caaphdvpb_63xqodmxkuf8vb9m7cxyuyt4swvegqequ-gb7q...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff
Temporarily install debugging in partition_prune test
The buildfarm animal parula has been sporadically failing in the
partition_prune test for the past week or so. It appears like an
auto-vacuum or auto-analyze has run on one of the partitions of the "ab"
table, causing the plan to change.
Trim ORDER BY/DISTINCT aggregate pathkeys in gather_grouping_paths
Similar to d8a295389, trim off any PathKeys which are for ORDER BY /
DISTINCT aggregate functions from the PathKey List for the Gather Merge
paths created by gather_grouping_paths(). These additional PathKeys are
not valid to use
Trim ORDER BY/DISTINCT aggregate pathkeys in gather_grouping_paths
Similar to d8a295389, trim off any PathKeys which are for ORDER BY /
DISTINCT aggregate functions from the PathKey List for the Gather Merge
paths created by gather_grouping_paths(). These additional PathKeys are
not valid to use
Fix incorrect filename reference in comment
Author: Cary Huang
Discussion:
https://postgr.es/m/18e34071af0.dbfc9663424635.8571906799773344...@highgo.ca
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fe4750effd61f5a37d18c48caa53892dbdcfb96d
Modified Files
, Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cahewxnnt6n6ujkya0z-jlfzvxcwgferqsfhiwa+nylg-x8i...@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/72b8507db2cc24810a29153838a62777d32f412f
, Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cahewxnnt6n6ujkya0z-jlfzvxcwgferqsfhiwa+nylg-x8i...@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/74530804fcb7a36175fa1268928cba98aa9e6cff
, Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cahewxnnt6n6ujkya0z-jlfzvxcwgferqsfhiwa+nylg-x8i...@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/348233cb128d32fd3a61f4473eda9564efdcd29c
, Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cahewxnnt6n6ujkya0z-jlfzvxcwgferqsfhiwa+nylg-x8i...@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e629846472255c7a636c453a522755ef05489c90
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
Fix deparsing of Consts in postgres_fdw ORDER BY
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw
On Fri, 8 Mar 2024 at 16:37, John Naylor wrote:
> Thanks, I was getting close to committing a hackish workaround -- this
> seems better!
ok cool. I also noticed a typo. Maybe worth fixing that at the same time?
Attached.
David
diff --git a/src/test/modules/test_radixtree/test_radixtree.c
On Fri, 8 Mar 2024 at 13:48, John Naylor wrote:
> Now, after I get some coffee I'll look into the Windows failures.
I had a look at this and the attached fixes the broken build on MSVC for me.
I didn't take the time to fully understand it, but I did also try
PGDLLEXPORT and that *didn't* fix
Remove surplus trailing semicolon
Author: Richard Guo
Discussion:
https://postgr.es/m/CAMbWs4-qjotfa7G=5peow4ldddx58mmtwddpdou3quse_bk...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2bce0ad67f93af6d1889ec611a8f618245291e3f
Modified Files
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Fix incorrectly reported stats kind in "can't happen" ERROR
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion:
Optimize GenerationAlloc() and SlabAlloc()
In a similar effort to 413c18401, separate out the hot and cold paths in
GenerationAlloc() and SlabAlloc() to avoid having to setup the stack frame
for the hot path.
This additionally adjusts how we use the GenerationContext's freeblock.
Freeblock, when
Support partition pruning on boolcol IS [NOT] UNKNOWN
While working on 4c2369ac5, I noticed we went out of our way not to
support clauses on boolean partitioned tables in the form of "IS
UNKNOWN" and "IS NOT UNKNOWN". It's almost as much code to disallow
this as it is to allow it, so let's allow
er setting
up the stack frame in AllocSetAlloc(), thus making the hot path much
cheaper.
Author: Andres Freund
Reviewed-by: David Rowley
Discussion:
https://postgr.es/m/20210719195950.gavgs6ujzmjfa...@alap3.anarazel.de
Branch
--
master
Details
---
https://git.postgresql.org/pg/
l.
To make checking the allocation request sizes and ERROR handling easier,
add some helper functions to mcxt.c for the allocators to use.
Author: Andres Freund
Reviewed-by: David Rowley
Discussion:
https://postgr.es/m/20210719195950.gavgs6ujzmjfa...@alap3.anarazel.de
Branch
--
master
D
Minor corrections for partition pruning
When the partition pruning code finds an OpExpr with an operator that
does not belong to the partition key's opfamily, the code checks to see
if the negator of the operator is the opfamily's BTEqualStrategyNumber
operator so that partition pruning can
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol
that if the relpages estimate is off a few
pages that the planner still shouldn't swap the join order.
Reported-by: Thomas Munro
Author: Andy Fan, David Rowley
Discussion:
https://postgr.es/m/CA+hUKGLqC-NobKYfjxNM3Gexv9OJ-Fhvy9bugUcXsZjTqH7W=q...@mail.gmail.com
Branch
--
master
Details
---
https
Simplify PathKey checking code
pathkeys_useful_for_ordering() contained some needless checks to return
0 when either root->query_pathkeys or pathkeys lists were empty. This is
already handled by pathkeys_count_contained_in(), so let's have it do the
work instead of having redundant checks.
Clarify the 'rows' parameter in create_append_path
This is extracted from a larger patch to improve the UNION planner.
While working on that, I found myself having to check what the 'rows'
parameter is for. It's not obvious that passing a negative number is the
way to have the rows estimate
UPPERREL_PARTIAL_DISTINCT.
Also, update the header comment for generate_gather_paths() to mention
the function is also used to create gather paths for partial distinct
paths.
Author: Richard Guo, David Rowley
Discussion:
https://postgr.es/m/cambws48u9vovooujsys1qoac9wvgvmba+wt1dx8kvxf5gpz
the
results into the Gather Merge. The non-parallel portion of the plan then
becomes very cheap as it leaves only Unique and Limit to do in the leader
process.
Author: Richard Guo
Reviewed-by: David Rowley
Discussion:
https://postgr.es/m/cambws48u9vovooujsys1qoac9wvgvmba+wt1dx8kvxf5gpz
as this could result in plan changes.
Author: Alexander Kuzmenkov
Reviewed-by: Ashutosh Bapat, Aleksander Alekseev, David Rowley
Discussion:
https://postgr.es/m/CALzhyqyhoXQDR-Usd_0HeWk%3DuqNLzoVeT8KhRoo%3DpV_KzgO3QQ%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg
w
matching the WHERE clause of the query takes a while to find. Parallel
workers could speed that process up considerably.
Author: Richard Guo
Reviewed-by: David Rowley
Discussion:
https://postgr.es/m/CAMbWs49JC0qvfUbzs-TVzgMpSSBiMJ_6sN=BaA9iohBgYkr=l...@mail.gmail.com
Branch
--
maste
On Mon, 29 Jan 2024 at 12:40, Michael Paquier wrote:
> Not sure if that's worth fixing if this should be gone at some point,
> but koel has been complaining on this one:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=koel=2024-01-28%2016%3A19%3A03
I think we should as we don't know
path on the cheapest partial path if an
incremental sort could be done instead.
This has the added benefit of reducing the amount of code required to
build these paths.
Author: Richard Guo
Reviewed-by: Etsuro Fujita, Shubham Khanna, David Rowley
Discussion:
https://postgr.es/m
Delay build of Memoize hash table until executor run
Previously this hash table was built during executor startup. This
could cause long delays in EXPLAIN (without ANALYZE) when the planner
opts to use a large Memoize hash table.
No backpatch for now due to lack of complaints.
Author: David
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
for transformFkeyCheckAttrs() also didn't mention
unique indexes, so fix that too. In passing make that header comment
reflect reality in the various other aspects where it deviated from it.
Bug: 18295
Reported-by: Gilles PARC
Author: Laurenz Albe, David Rowley
Discussion:
https://www.postgresql.org
1 - 100 of 751 matches
Mail list logo
