running Fedora 39 and should occur
in many other distributions also.
I think a self compiled version of postgres should be self-confined and ready
to run for testing.
Any thoughts?
Hans Buschmann
p Chakraborty, Michael Paquier)
perhaps you mean Allow, otherwise meaning not clear.
3.
>> Add some long options to pg_archivecleanup (Atsushi Torikoshi)
>>The long options are --debug, --dry-run, and /--strip-extension.
The slash should be omitted.
Hans Buschmann
ing usability
All these points are from my real world experience of usablity of Postgres. I
have managed to learn or circumvent specific aspects, but I think usability for
every not so skilled user should be in the main focus.
Please see my suggestions this way!
Hans Buschmann
__
quot; exists already in the
index)
I just sent this message for the case this could be a problem to be resolved
before the next minor versions scheduled for next week.
Regards
Hans Buschmann
Von: David Rowley
Gesendet: Donnerstag, 2. Mai 2024 13:33
An: Hans
-0), 64-bit
(1 Zeile)
postgres=# select -32768::smallint;
ERROR: smallint out of range
Thank you for looking
Hans Buschmann
nstallations. [2]
(CC Devrim according to the thread Security lessons from libzlma - libsystemd)
regards
Hans Buschmann
[1] https://www.postgresql.org/message-id/flat/ZgdCpFThi9ODcCsJ%40momjian.us
[2]
https://www.postgresql.org/message-id/18339-f9dda01a46c0432f%40postgresql.org
harmless where clause (where nlen > 0)
to a just working query and got the error.
Other where-clauses (where nnum < 100) cause the same error.
Operator classes which could error out should not be applied for filtering
columns from relations, which are not the outermost relation in joins and could
be eliminated by another join.
These queries are syntactically and semantically correct but the postgre
implementations causes them to error out.
This is very surprising for the SQL User!
The problem seems to exist also in certain backbranches.
Hans Buschmann
<>
Tom Lane writes:
>Hans Buschmann writes:
>> This inspired me to propose dropping 32bit support for PostgreSQL starting
>> with PG17.
>I don't think this is a great idea. Even if Intel isn't interested,
>there'll be plenty of 32-bit left in the lower end of
2028.
Even if I am not a postgres hacker I suppose this could simplify things quite a
lot.
Any thoughts for discussion are welcome!
Hans Buschmann
[1] https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
?)
Hans Buschmann
I observed a missing end bracket in E 1.3.11:
Require Windows 10 or newer versions (Michael Paquier, Juan José SantamarÃa
Flecha
Hans Buschmann
_1 (cost=0.00..294.22 rows=5944
width=72) (actual time=0.029..1.056 rows=424 loops=1)
Filter: ((ibitmask < 0) OR (cardinality(mat_arr) > 11))
Rows Removed by Filter: 10275
Planning Time: 1.746 ms
Execution Time: 13405.503 ms
(116 Zeilen)
This case really brought me to detect the problem!
The original query and data are not shown here, but the principle should be
clear from the execution plans.
I think the planner shouldn't change the row estimations on further steps after
left joins at all, and be a bit more conservative on inner joins.
This may be related to the fact that this case has 2 join-conditions (xx_season
an xx_code).
Thanks for looking
Hans Buschmann
hem to NOT NULL, which seems the most natural way when these quals are also
used for partioning.
[1] https://www.postgresql.org/message-id/1571413123735.26...@nidsa.net
Thanks for looking
Hans Buschmann
INTENTION
Inspired by the effort to integrate JIT for executor acceleration I thought
selected simple algorithms working with array-oriented data should be
drastically accelerated by using SIMD instructions on modern hardware.
I want to introduce this style of programming with the example of he
with VS2019 and VS2022) albeit not excluded explicitly
in the docs. But no one complained yet (for a long time now...).
Thanks
Hans Buschmann
relations to EDB suggesting them to target VS2022 as
the build environment for the upcoming PG15 release?
postgres=# select version ();
version
PostgreSQL 14.1, compiled by Visual C++ build 1931, 64-bit
(1 row)
T
version v4.
Due to my restricted devlopment environment I appreciate if anybody can test
the resulting binaries (but MS seems not have changed much on the C Build
environment internally).
Thanks
Hans Buschmann
0001_support_vs2022_v4.patch
Description: 0001_support_vs2022_v4.patch
elsewhere in the postgres source
tree.
I will reflect any updates after official release on monday, November 8
Hans Buschmann
0001_support_vs2022_v2.patch
Description: 0001_support_vs2022_v2.patch
Perhaps someone could jump in
...
Thanks for the patch and awaiting your thoughts
Hans Buschmann
further work under the way (not yet ready), pg_dump can really
profit from parallel/not compressing mode, especially considering the huge
amount of bytea/blob/string data in many big customer scenarios.
Thoughts?
Hans Buschmann
PG
without errors.
Thanks
Hans Buschmann
Von: Michael Paquier
Gesendet: Montag, 11. Oktober 2021 08:03
An: Andrew Dunstan
Cc: Laurenz Albe; Hans Buschmann; pgsql-hack...@postgresql.org
Betreff: Re: VS2022: Support Visual Studio 2022 on Windows
On Mon
building the 32bit
version, but this has to be discussed in another thread (if the Windows 32bit
Version is still important to support on newer VS Versions)
Thanks for looking at it
Hans Buschmann
0001_support_vs2022.patch
Description: 0001_support_vs2022.patch
Von: Ranier Vilela
Gesendet: Montag, 16. August 2021 17:04
An: Hans Buschmann
Cc: pgsql-hack...@postgresql.org
Betreff: Re: PG14: Avoid checking output-buffer-length for every encoded byte
during pg_hex_encode
Hello Ranier,
Thank you for your quick response
es on Windows).
If it seems useful somebody could enter it as an open item / resolved item for
pg14 after beta 3.
Thanks for looking!
Hans Buschmann
hex_encode_length_check_outside_loop.patch
Description: hex_encode_length_check_outside_loop.patch
the constants away there my be a special case where all hash
conditions are constants, so a hash table has not to be build (or at least one
hash cond has to be preserved).
Hans Buschmann
the whole fact table will be joined.
To me it seems that the "constantness" is not propagated to all equivalence
columns and not considered in hash joining.
Unfortunely I am not in the position to write a patch, so I would appreciate
any help to get this optimization realized.
Muc
performance tests.
I want to bring this to notice to everyone to determine if there is an impact
of this change for Postgres too.
Perhaps someone can check it out in the process of PG11 maturing.
Thanks
Hans Buschmann
27 matches
Mail list logo
