On Mon, Sep 07, 2020 at 10:16:25PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> Add support for partitioned tables and indexes in REINDEX
>
> Buildfarm isn't finding the isolation test to be stable.
Yes, I have noticed the failure, and waited for more data to gather
while thinking about w
Remove isolation test reindex-partitions
The isolation test added by a6642b3 is proving to be unstable, as once
the first transaction holding a lock on the top-most partitioned table
or on a partition commits, the commit order of the follow-up DROP TABLE
and REINDEX could become reversed depending
Michael Paquier writes:
> Add support for partitioned tables and indexes in REINDEX
Buildfarm isn't finding the isolation test to be stable.
regards, tom lane
Add support for partitioned tables and indexes in REINDEX
Until now, REINDEX was not able to work with partitioned tables and
indexes, forcing users to reindex partitions one by one. This extends
REINDEX INDEX and REINDEX TABLE so as they can accept a partitioned
index and table in input, respect
Adjust cost model for HashAgg that spills to disk.
Tomas Vondra observed that the IO behavior for HashAgg tends to be
worse than for Sort. Penalize HashAgg IO costs accordingly.
Also, account for the CPU effort of spilling the tuples and reading
them back.
Discussion: https://postgr.es/m/2020090
Adjust cost model for HashAgg that spills to disk.
Tomas Vondra observed that the IO behavior for HashAgg tends to be
worse than for Sort. Penalize HashAgg IO costs accordingly.
Also, account for the CPU effort of spilling the tuples and reading
them back.
Discussion: https://postgr.es/m/2020090
Clarify comments in enforce_generic_type_consistency().
Some of the pre-existing comments were vague about whether they
referred to all polymorphic types or only the old-style ones.
Also be more consistent about using the "family 1" vs "family 2"
terminology.
Himanshu Upadhyaya and Tom Lane
Dis
Clarify comments in enforce_generic_type_consistency().
Some of the pre-existing comments were vague about whether they
referred to all polymorphic types or only the old-style ones.
Also be more consistent about using the "family 1" vs "family 2"
terminology.
Himanshu Upadhyaya and Tom Lane
Dis
Alvaro Herrera writes:
> On 2020-Sep-07, Tom Lane wrote:
>> If there were something to be on the warpath about, it's that initdb
>> is pulling in such an obviously backend-only header as that. I wonder
>> if we should refactor to fix that.
> Hmm, if we wanted to clean things up I think we should
On 2020-Sep-07, Tom Lane wrote:
> If there were something to be on the warpath about, it's that initdb
> is pulling in such an obviously backend-only header as that. I wonder
> if we should refactor to fix that.
>
> Quick experimentation says that the symbols initdb actually needs out
> of that
Alvaro Herrera writes:
> On 2020-Sep-07, Tom Lane wrote:
>> I didn't bother tracking down exactly where initdb.c is getting
>> stringinfo.h from, but it clearly does import it somewhere in
>> our rat's nest of headers.
> You can see it here: https://doxygen.postgresql.org/initdb_8c.html
> It's th
po 7. 9. 2020 v 18:58 odesílatel Alvaro Herrera
napsal:
> On 2020-Sep-07, Tom Lane wrote:
>
> > Pavel Stehule writes:
> > > here is a patch
> >
> > What exactly is this supposed to fix?
> >
> > I didn't bother tracking down exactly where initdb.c is getting
> > stringinfo.h from, but it clearly
On 2020-Sep-07, Tom Lane wrote:
> Pavel Stehule writes:
> > here is a patch
>
> What exactly is this supposed to fix?
>
> I didn't bother tracking down exactly where initdb.c is getting
> stringinfo.h from, but it clearly does import it somewhere in
> our rat's nest of headers.
You can see it
Pavel Stehule writes:
> here is a patch
What exactly is this supposed to fix?
I didn't bother tracking down exactly where initdb.c is getting
stringinfo.h from, but it clearly does import it somewhere in
our rat's nest of headers.
regards, tom lane
po 7. 9. 2020 v 16:48 odesílatel Tom Lane napsal:
> Alvaro Herrera writes:
> > On 2020-Sep-07, Pavel Stehule wrote:
> >> I tried to reuse this new API in pg_dump.c, and I had a problem with
> >> private struct StringInfo.
>
> >> maybe there should be included directly with #include
> "lib/strin
Frob numeric.c loop so that clang will auto-vectorize it too.
Experimentation shows that clang will auto-vectorize the critical
multiplication loop if the termination condition is written "i2 < limit"
rather than "i2 <= limit". This seems unbelievably stupid, but I've
reproduced it on both clang
Alvaro Herrera writes:
> On 2020-Sep-07, Pavel Stehule wrote:
>> I tried to reuse this new API in pg_dump.c, and I had a problem with
>> private struct StringInfo.
>> maybe there should be included directly with #include "lib/stringinfo.h" ?
> That's the right thing to do, yes.
Yeah, if you wa
On 2020-Sep-07, Pavel Stehule wrote:
> I tried to reuse this new API in pg_dump.c, and I had a problem with
> private struct StringInfo.
> maybe there should be included directly with #include "lib/stringinfo.h" ?
That's the right thing to do, yes.
--
Álvaro Herrerahttps://www
Add d_type to our Windows dirent emulation.
This allows us to skip some stat calls, by extending commit 861c6e7c to
cover Windows systems.
Author: Juan José Santamaría Flecha
Reviewed-by: Alvaro Herrera
Reviewed-by: Andres Freund
Reviewed-by: Magnus Hagander
Reviewed-by: Thomas Munro
Discuss
doc: Fix table cell overflow
Fix one instance of a table cell overflow by adding a zero-width
space. The visual impact of this is minimal, but since this is
currently the only such case reported by FOP ("contents of ... exceed
the available area"), it seems worth getting rid of.
Branch
--
ma
Update list of acknowledgments in release notes
current through b7cf9e42ac2d4b153eb781195ebf369d4b8b566e
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1e83138da14d61d572b0b58a9da6a2cf535ea198
Modified Files
--
doc/src/sgml/release-13.sgml | 8 +
21 matches
Mail list logo
