On Sun, Jun 1, 2025, at 18:04, Tom Lane wrote:
> I'm pretty skeptical that this situation justifies the amount of
> pg_depend bloat that you're suggesting. I also don't think it'd be
> easy or cheap for pg_dump to detect objects that should be dumped
> because they lack an 'e' dependency but depen
On Sun, Jun 1, 2025, at 08:24, Joel Jacobson wrote:
> On Sat, May 31, 2025, at 23:56, Tom Lane wrote:
>> "Joel Jacobson" writes:
>>> Foreign key constraints created during CREATE EXTENSION
>>> lack a pg_depend entry with deptype='e'.
>>
&g
On Sat, May 31, 2025, at 23:56, Tom Lane wrote:
> "Joel Jacobson" writes:
>> Foreign key constraints created during CREATE EXTENSION
>> lack a pg_depend entry with deptype='e'.
>
> Why would it be a sensible thing for an extension to create a
> forei
Hi hackers,
Foreign key constraints created during CREATE EXTENSION
lack a pg_depend entry with deptype='e'.
Looking at the code, I found that CreateConstraintEntry() in
src/backend/catalog/pg_constraint.c does not call
recordDependencyOnCurrentExtension(), unlike most other CREATE functions.
Th
On Sat, Apr 26, 2025, at 05:10, Tom Lane wrote:
> "Joel Jacobson" writes:
>> For years, I've felt we could benefit from introducing convenience syntax to
>> explicitly require that exactly one row is affected by a query, something
>> which
>> curr
On Sat, Apr 26, 2025, at 06:44, Tom Lane wrote:
> This is a rather delayed response to the discussion of bug
> #18693 [1], in which I wrote:
...
> which is pretty bogus because the record *does* have a field
> named "strict". The actual problem is that STRICT is a fully
> reserved PL/pgSQL keyword
On Wed, Mar 5, 2025, at 03:32, Andreas Karlsson wrote:
> On 3/4/25 10:24 AM, Andreas Karlsson wrote:
>> Rebased the patch to add support for OLD.* and NEW.*.
>
> Apparently the CI did not like that version.
>
> Andreas
>
> Attachments:
> * v6-0001-Add-support-for-ON-CONFLICT-DO-SELECT-FOR.patch
+1
On Thu, Dec 19, 2024, at 14:40, Andrew Dunstan wrote:
> We seem to have got seriously into the weeds, here. I'd be sorry to see
> this dropped. After all, it's not something new, and while we have a
> sort of workaround for "one json doc per line" it's far from obvious,
> and except in a few blo
On Thu, Dec 19, 2024, at 07:48, jian he wrote:
> I have reviewed v21-0001 again.
>
> v21-0001-Introduce-CopyFormat-and-replace-csv_mode-and-binary.patch
> is a good refactor.
>
>
> overall looks good to me.
OK, I could submit it as a separate patch.
Would we also want the reorganization of existi
Hi hackers,
As noted in previous feedback, relying on pg_shdepend leads to a less-than-ideal
behavior: no privileges are displayed for an object until at least one privilege
is granted to a role other than the owner, as explained by Alvaro:
On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>
Hi hackers,
After further consideration, I'm withdrawing the patch.
Some fundamental questions remain unresolved:
- Should round-trip fidelity be a strict goal? By "round-trip fidelity",
I mean that data exported and then re-imported should yield exactly
the original values, including the dis
On Tue, Dec 3, 2024, at 09:52, Andreas Karlsson wrote:
> Hi,
>
> Here is an updated version of the patch which fixes a few small bugs,
> including making sure it checks the update permission plus a bug found
> by Joel Jacobsson when it was called by SPI.
+1 for this feature.
This seems especial
On Sun, Nov 10, 2024, at 23:14, Tom Lane wrote:
> "Joel Jacobson" writes:
>> On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
>>> That seems like a hack, as it also changes the behavior w.r.t.
>>> prompts and EOF-mark detection, neither for the better.
>
On Sun, Nov 10, 2024, at 22:37, Tom Lane wrote:
> "Joel Jacobson" writes:
>> Fix by adjusting handleCopyIn() to use the binary code path also when the
>> copy
>> source is a file (i.e., copystream != pset.cur_cmd_source), even in textual
>> copies.
>
>
Hi hackers,
When using \copy from in psql to import files containing NUL bytes (\0) in
'text' or 'csv' format, the NUL bytes were not detected and did not result in
an error, leading to silent data corruption.
This behavior is inconsistent with server-side COPY FROM, which reports an error
upon e
On Sun, Nov 10, 2024, at 09:00, Joel Jacobson wrote:
>> It's a bit of a hack, but I kinda like it., since it seems like the
>> only option without an error situation.
I forgot about the error situation when a textual contain
newline characters, that remains the same for option A, B and C.
/Joel
On Sun, Nov 10, 2024, at 08:48, Joel Jacobson wrote:
> On Sun, Nov 10, 2024, at 08:32, Joel Jacobson wrote:
>> Option A:
>> COPY TO: Empty string field gets exported as an empty line. NULL field
>> is an error.
>> COPY FROM: Empty line is imported as an empty string.
On Sun, Nov 10, 2024, at 08:32, Joel Jacobson wrote:
> Option A:
> COPY TO: Empty string field gets exported as an empty line. NULL field
> is an error.
> COPY FROM: Empty line is imported as an empty string.
>
> Option B:
> COPY TO: NULL field gets exported as an empty lin
On Sun, Nov 10, 2024, at 05:55, David G. Johnston wrote:
> On Saturday, November 9, 2024, jian he wrote:
>>
>> The list format does not distinguish a
>> NULL
>> value from an empty string. Empty lines are imported as empty strings,
>> not
>> as NULL values.
>>
>> we only ment
On Sun, Nov 10, 2024, at 05:26, jian he wrote:
> On Sun, Nov 10, 2024 at 3:29 AM Joel Jacobson wrote:
>>
>> Cool. I've drafted a new patch on this approach.
>> The list of newline-free built-in types is not exhaustive, yet.
>
>
> do we care that COPY back a
On Sat, Nov 9, 2024, at 15:28, David G. Johnston wrote:
> PostgreSQL cannot store the NUL byte. Would that be an option for the
> record separator. Default to new line but accept NUL if one needs to
> input/output lists containing newlines. Or whatever character the user
> believes is not par
On Sat, Nov 9, 2024, at 15:13, David G. Johnston wrote:
> On Saturday, November 9, 2024, Joel Jacobson wrote:
>> On Sat, Nov 9, 2024, at 08:07, Joel Jacobson wrote:
>> > Here's a draft of an idea I'm considering (not yet implemented):
>>
>> I realize
On Sat, Nov 9, 2024, at 08:07, Joel Jacobson wrote:
> Here's a draft of an idea I'm considering (not yet implemented):
I realize the last part about optional quoting is unnecessary,
since if quoting is desired, users could just use the 'csv' format.
Revised draft of the id
On Fri, Nov 8, 2024, at 22:47, David G. Johnston wrote:
> On Fri, Nov 8, 2024 at 2:20 PM Joel Jacobson wrote:
>>
>> 1. Text files containing \. in the middle of the file
>> % cat /tmp/test.txt
>> foo
>> \.
>> bar
>>
>> Or another option to tur
On Fri, Nov 8, 2024, at 20:44, Daniel Verite wrote:
> Aleksander Alekseev wrote:
>
>> IMO it should be 'text' we already have with special options e.g.
>> DELIMITER AS NULL ESCAPE AS NULL. If there are no escape characters
>> and column delimiters (and no NULLs designations, and what else I
>> forg
On Thu, Nov 7, 2024, at 17:15, Joel Jacobson wrote:
> Attachments:
> * v18-0001-Introduce-CopyFormat-and-replace-csv_mode-and-binary.patch
> * v18-0002-Add-COPY-format-single.patch
> * v18-0003-Reorganize-option-validations.patch
I want to bring up a potential problem with v18, wh
, some of us came to the conclusion that it would be
better to introduce a new format, for reasons explained below,
quoted from the old thread [1]:
On Wed, Oct 9, 2024, at 18:14, Andrew Dunstan wrote:
> On 2024-10-09 We 11:58 AM, Tom Lane wrote:
>> "Joel Jacobson" writes:
>&
On Fri, Nov 8, 2024, at 08:42, Joel Jacobson wrote:
>> I’d be concerned choosing “single” given this future possibility. I do
>> agree that such an enhancement would be best done in its own patch.
>
> OK, sounds good to do it in its own patch.
>
> If the name "
On Fri, Nov 8, 2024, at 07:14, David G. Johnston wrote:
> On Thursday, November 7, 2024, Joel Jacobson wrote:
>> On Fri, Nov 8, 2024, at 00:13, Masahiko Sawada wrote:
>> > In earlier versions, we supported loading the whole file into a single
>> > tuple. Is there
On Fri, Nov 8, 2024, at 00:13, Masahiko Sawada wrote:
> In earlier versions, we supported loading the whole file into a single
> tuple. Is there any reason that it doesn't support it in v18? I think
> if it's useful we can improve it in a separate patch.
Not sure how useful it is, since we already
Thread renamed to: New "single" COPY format [1]
[1] https://postgr.es/m/1db18e33-f1cf-4f2c-9d52-b6d7ff242...@app.fastmail.com
/Joel
Hi hackers,
Thread [1] renamed, since the format name has now been changed from 'raw' to
'single', as suggested by Andrew Dunstan and Jacob Champion.
[1] https://postgr.es/m/c12516b1-77dc-4ad3-94a7-88527360a...@app.fastmail.com
Recap: This is about adding support to import/export text-based form
On Mon, Nov 4, 2024, at 19:34, Masahiko Sawada wrote:
> On Sat, Nov 2, 2024 at 4:08 AM Joel Jacobson wrote:
>>
>> On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
>> > As I mentioned in a separate email, if we use the OS default EOL as
>> > the default E
On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
> As I mentioned in a separate email, if we use the OS default EOL as
> the default EOL in raw format, it would not be necessary to allow it
> to be multi characters. I think it's worth considering it.
I like the idea, but not sure I understand
On Mon, Oct 28, 2024, at 18:50, Masahiko Sawada wrote:
> Thank you for updating the patch. Here are review comments on the v15
> 0002 patch:
Thanks for review.
> When testing the patch with an empty delimiter, I got the following failure:
>
> postgres(1:903898)=# copy hoge from '/tmp/tmp.raw' wit
Hi hackers,
I've noticed some inconsistency in 002_pg_upgrade.pl in how it handles output
during test failures. Currently, it uses note to print the header:
note "=== contents of $log ===\n";
but print for the log content and footer:
print slurp_file($log);
print "=== EOF ===\n";
T
On Mon, Oct 28, 2024, at 13:44, Daniel Gustafsson wrote:
>> On 28 Oct 2024, at 13:38, Joel Jacobson wrote:
>>
>> Hi hackers,
>>
>> I've noticed some inconsistency in 002_pg_upgrade.pl in how it handles output
>> during test failures. Currently, it uses
On Mon, Oct 28, 2024, at 10:30, Joel Jacobson wrote:
> On Mon, Oct 28, 2024, at 08:56, jian he wrote:
>> /* Check force_quote */
>> - if (!opts_out->csv_mode && (opts_out->force_quote ||
>> opts_out->force_quote_all))
>> + if (opts_out->form
On Mon, Oct 28, 2024, at 08:56, jian he wrote:
> /* Check force_quote */
> - if (!opts_out->csv_mode && (opts_out->force_quote ||
> opts_out->force_quote_all))
> + if (opts_out->format != COPY_FORMAT_CSV && (opts_out->force_quote ||
> + opts_out->force_quote_all))
> ereport(ERROR,
> (errcode(
On Sat, Oct 19, 2024, at 09:52, Joel Jacobson wrote:
> However, since my last email, I've found some other problems in this area,
> and think we should do a more ambitious improvement, by rearranging the
> incorrect options tests into three categories:
>
> 1. incorrect COPY {
On Thu, Oct 24, 2024, at 03:54, Masahiko Sawada wrote:
> I have one question:
>
> From the 0001 patch's commit message:
>
> No behavioral changes are intended; this is a pure refactoring to improve code
> clarity and maintainability.
>
> Does the reorganization of the option validation done by this
On Mon, Oct 21, 2024, at 16:35, jian he wrote:
> make the ProcessCopyOptions process in following order:
> 1. Extract options from the statement node tree
> 2. checking each option, if not there set default value.
> 3. checking for interdependent options
>
> I still think
> making step2 aligned wit
On Mon, Oct 21, 2024, at 11:06, Aleksander Alekseev wrote:
> Hi,
>
> Recently I wanted to call array_reverse() and discovered that we still
> don't have it. I'm not the first one who encountered this limitation.
> array_reverse() was requested at least since 2009 [1] and the
> workaround on Postgre
On Mon, Oct 21, 2024, at 11:42, Alvaro Herrera wrote:
> ... actually, the "AND pg_shdepend.dbid = ( SELECT pg_database_1.oid
> ...)" part of this is useless, because you already had that in the ON
> condition of the original join to pg_database. So, apologies for the
> noise there. TBH I don't se
On Sun, Oct 20, 2024, at 23:03, Joel Jacobson wrote:
> On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote:
>> On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>>> I think the function calls should be in the FROM clause, and restrict the
>>> pg_shdepend rows to o
On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote:
> On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>> I think the function calls should be in the FROM clause, and restrict the
>> pg_shdepend rows to only the ones in the current database:
>
> Cool. I assume pg_ownersh
On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
> I think the function calls should be in the FROM clause, and restrict the
> pg_shdepend rows to only the ones in the current database:
Cool. I assume pg_ownerships should be changed in the same way?
New patch attached.
> Now, depending on pg
Hi hackers,
Here is an attempt to revive this patch from 2021-2022, that has been ready now
for a while, thanks to pg_get_acl() function that was committed in
4564f1c and d898665.
I've renamed the $subject of the email thread, to match the commitfest entry:
https://commitfest.postgresql.org/50/50
On Sat, Oct 19, 2024, at 12:13, jian he wrote:
> We already make RAW and can only have one column.
> if RAW has no default delimiter, then COPY FROM a text file will
> become one datum value;
> which makes it looks like importing a Large Object.
> (https://www.postgresql.org/docs/17/lo-funcs.html)
On Fri, Oct 18, 2024, at 19:24, Joel Jacobson wrote:
> Attachments:
> * v11-0001-Refactor-ProcessCopyOptions-introduce-CopyFormat-enu.patch
> * v11-0002-Add-raw-format-to-COPY-command.patch
Here is a demo of a importing a decently sized real text file,
that can't currently be import
On Sat, Oct 19, 2024, at 03:32, Michael Paquier wrote:
> If this area of the code is refactored so as a different error is
> triggered for these two specific queries, we'd still be alerted that
> something is wrong the same way for HEAD or what you are suggesting.
> I can see your argument, but it
On Fri, Oct 18, 2024, at 15:52, jian he wrote:
> Raw Format is duplicated
> Raw Format didn't mention the special handling of
> end-of-data marker.
Thanks for reviewing, above fixed.
Here is a summary of the changes since v10, thanks to the feedback:
Handling of e.g. JSON and other structured t
On Fri, Oct 18, 2024, at 00:52, Michael Paquier wrote:
> On Thu, Oct 17, 2024 at 10:21:54AM +0200, Joel Jacobson wrote:
>> I believe the correction should be to use COPY TO stdout instead of
>> COPY FROM stdin, since FORCE_QUOTE is only applicable with COPY TO.
>> This wa
On Wed, Oct 16, 2024, at 21:13, Joel Jacobson wrote:
> Therefore, maybe DELIMITER NONE would be a better default
> for RAW? Especially since it's then also more honest in being "raw".
>
> If needing to import an unstructured text file that is just newline
> delimit
On Thu, Oct 17, 2024, at 01:50, Michael Paquier wrote:
> On Wed, Oct 16, 2024 at 02:50:53PM +0900, Michael Paquier wrote:
>> You are right. f6d4c9cf162b got that wrong. Will fix and backpatch
>> with the extra tests.
>
> And done down to 17 for 0002, down to 16 for 0001, with tweaks in 0001
> to
On Wed, Oct 16, 2024, at 20:30, Joel Jacobson wrote:
> A final thought is to maybe consider just skipping
> the automagical newline detection for RAW?
>
> Instead of the automagical detection,
> the default newline delimiter could be the OS default,
> similar to how COPY TO works
On Wed, Oct 16, 2024, at 18:34, Daniel Verite wrote:
> Joel Jacobson wrote:
>
>> However, I thinking rejecting such column data seems like the
>> better alternative, to ensure data exported with COPY TO
>> can always be imported back using COPY FROM,
>> for the same
On Wed, Oct 16, 2024, at 18:04, Jacob Champion wrote:
> A hypothetical type whose text representation can contain '\r' but not
> '\n' still can't be unambiguously round-tripped under this scheme:
> COPY FROM will see the "mixed" line endings and complain, even though
> there's no ambiguity.
Yeah,
On Wed, Oct 16, 2024, at 05:31, jian he wrote:
> Hi.
> I only checked 0001, 0002, 0003.
> the raw format patch is v9-0016.
> 003-0016 is a lot of small patches, maybe you can consolidate it to
> make the review more easier.
Thanks for reviewing.
OK, I've consolidated the v9 0003-0016 into a singl
On Tue, Oct 15, 2024, at 19:30, Jacob Champion wrote:
> Hi,
>
> Idle thoughts from a design perspective -- feel free to ignore, since
> I'm not the target audience for the feature:
Many thanks for looking at this!
> - If the column data stored in Postgres contains newlines, it seems
> like COPY T
On Mon, Oct 14, 2024, at 10:51, Joel Jacobson wrote:
> On Mon, Oct 14, 2024, at 10:07, Joel Jacobson wrote:
>> Attached is a first draft implementation of the new proposed COPY "raw"
>> format.
>>
>> The first two patches are just the bug fix i
On Mon, Oct 14, 2024, at 10:07, Joel Jacobson wrote:
> Attached is a first draft implementation of the new proposed COPY "raw"
> format.
>
> The first two patches are just the bug fix in HEAD, reported separately:
> https://commitfest.postgresql.org/50/5297/
I forgot abo
On Sun, Oct 13, 2024, at 14:39, Joel Jacobson wrote:
> On Sun, Oct 13, 2024, at 11:52, Tatsuo Ishii wrote:
>> After copy imported the "unstructured text file" in "row" COPY format,
>> what the column type is? text? or bytea? If it's text, how do
On Sun, Oct 13, 2024, at 11:52, Tatsuo Ishii wrote:
> After copy imported the "unstructured text file" in "row" COPY format,
> what the column type is? text? or bytea? If it's text, how do you
> handle encoding conversion if the "unstructured text file" is encoded
> in server side unsafe encoding
On Sat, Oct 12, 2024, at 02:48, jian he wrote:
> git version 2.34.1
> cannot do `git apply`
Sorry about that, fixed.
> typedef enum CopyFormat
> {
> COPY_FORMAT_TEXT,
> COPY_FORMAT_BINARY,
> COPY_FORMAT_CSV
> } CopyFormat;
Thanks, fixed.
> CopyFormat should add to
> src/tools/pginde
On Sat, Oct 12, 2024, at 01:48, Joel Jacobson wrote:
> Hi hackers,
>
> Here is a patch that fixes a minor problem in copy.c's ProcessCopyOptions,
> as well as fixing thinko in its tests, as well as adding new tests for
> the bugfix.
Rebase only.
/Joel
v2-0001-Fix-thin
Hi hackers,
Here is a patch that fixes a minor problem in copy.c's ProcessCopyOptions,
as well as fixing thinko in its tests, as well as adding new tests for
the bugfix.
[PATCH 1/2] Fix thinko in tests for COPY options force_not_null
and force_null.
Use COPY FROM for the negative tests that chec
On Fri, Oct 11, 2024, at 22:29, Joel Jacobson wrote:
> Hi hackers,
>
> This thread is about implementing a new "raw" COPY format.
...
> The attached patch implements the above ideas.
>
> I think with these changes, it would be easier to hack on new and existin
Hi hackers,
This thread is about implementing a new "raw" COPY format.
This idea came up in a different thread [1], moved here.
[1] https://postgr.es/m/47b5c6a7-5c0e-40aa-8ea2-c7b95ccf296f%40app.fastmail.com
The main use-case for the raw format, is when needing to import arbitrary
unstructured
On Fri, Oct 11, 2024, at 15:04, Joel Jacobson wrote:
> On Thu, Oct 10, 2024, at 10:37, Daniel Verite wrote:
>> Joel Jacobson wrote:
>>
>>> - No Headers or Metadata:
>>
>> It's not clear why it's necessary to disable the HEADER option
>> for th
On Thu, Oct 10, 2024, at 10:37, Daniel Verite wrote:
> Joel Jacobson wrote:
>
>> - No Headers or Metadata:
>
> It's not clear why it's necessary to disable the HEADER option
> for this format?
It's not necessary, no, just couldn't see a use-case,
sinc
On Wed, Oct 9, 2024, at 14:45, Andrew Dunstan wrote:
> On 2024-10-09 We 8:00 AM, Andrew Dunstan wrote:
>> On 2024-10-08 Tu 3:25 AM, Joel Jacobson wrote:
>>> 2b) Should we aim to only support the QUOTE NONE DELIMITER NONE
>>> ESCAPE NONE case,
>>> useful to the
On Tue, Oct 8, 2024, at 11:06, Amul Sul wrote:
> The attached patch proposes adding the ability to define CHECK and
> FOREIGN KEY constraints as NOT ENFORCED.
Thanks for working on this!
> Adding NOT ENFORCED to CHECK constraints is simple, see 0001 patch,
I've looked at the 0001 patch and think
On Tue, Oct 8, 2024, at 03:48, Michael Paquier wrote:
> On Thu, Jun 13, 2024 at 07:34:30AM +0200, Joel Jacobson wrote:
>> Hmm, strange, the commitfest system didn't pick up the email with patch 0006
>> for some reason,
>> with message id 0c5a6b79-408c-4910-9b2e-4aa
On Sun, Oct 6, 2024, at 15:12, Andrew Dunstan wrote:
> On 2024-10-04 Fr 12:19 PM, Joel Jacobson wrote:
>> 2. Avoid needing hacks like using E'\x01' as quoting char.
>>
>> Introduce QUOTE NONE and DELIMITER NONE,
>> to allow raw lines to be imported "
On Sun, Jul 2, 2023, at 07:45, Noah Misch wrote:
> On Sat, May 20, 2023 at 09:16:30AM +0200, Joel Jacobson wrote:
>> On Fri, May 19, 2023, at 18:06, Daniel Verite wrote:
>> > COPY FROM file CSV somewhat differs as your example shows,
>> > but it still mishandle \.
On Wed, Sep 4, 2024, at 09:22, Dean Rasheed wrote:
> On Tue, 3 Sept 2024 at 21:31, Tom Lane wrote:
>>
>> Dean Rasheed writes:
>> > Ah, OK. I've pushed a fix.
>>
>> There is an open CF entry pointing at this thread [1].
>> Shouldn't it be marked committed now?
>>
>
> Oops, yes I missed that CF ent
On Sat, Aug 24, 2024, at 14:10, Dean Rasheed wrote:
> On Sat, 24 Aug 2024 at 08:26, Joel Jacobson wrote:
>>
>> On Sat, Aug 24, 2024, at 01:35, Joel Jacobson wrote:
>> > On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
>> >> Since statistical tools that r
On Sat, Aug 24, 2024, at 01:35, Joel Jacobson wrote:
> On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
>> Since statistical tools that rely on normal distributions can't be used,
>> let's look at the individual measurements for (var1ndigits=3, var2ndigits=3)
>
On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
> Since statistical tools that rely on normal distributions can't be used,
> let's look at the individual measurements for (var1ndigits=3, var2ndigits=3)
> since that seems to be the biggest slowdown on both CPUs,
> a
On Fri, Aug 23, 2024, at 21:21, Joel Jacobson wrote:
> Attachments:
> * perf_test-M3 Max.out
> * perf_test-Intel Core i9-14900K.out
> * perf_test-AMD Ryzen 9 7950X3D.out
Here are some additional benchmarks from pg-catbench:
AMD Ryzen 9 7950X3D:
select x var1ndigits,y
var2ndigits
On Fri, Aug 23, 2024, at 21:21, Joel Jacobson wrote:
> On Fri, Aug 23, 2024, at 15:49, Dean Rasheed wrote:
>> The attached patch attempts to resolve those issues by replacing
>> div_var() and div_var_fast() with a single function intended to be
>> faster than both the origina
On Wed, Aug 14, 2024, at 19:25, Joel Jacobson wrote:
> What do we want to happen if passing a numeric with decimal digits,
> to decimal_to_bytes()? It must be an error, right?
>
> Example: SELECT decimal_to_bytes(1.23);
Hmm, an error feels quite ugly on second thought.
Would be
On Wed, Aug 14, 2024, at 18:31, David Fetter wrote:
> On Wed, Aug 14, 2024 at 05:39:32PM +0200, Joel Jacobson wrote:
>> On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
>> >> I also think it would be nice to provide these convenience functions:
>> >> to_bytes(
On Wed, Aug 14, 2024, at 16:43, David Fetter wrote:
>> I also think it would be nice to provide these convenience functions:
>> to_bytes(bigint) -> bytea
>> from_bytes(bytea) -> bigint
>
> Along with these, would it make sense to have other forms of these
> that won't choke at 63 bits, e.g. NUMERIC
On Wed, Aug 14, 2024, at 13:31, Aleksander Alekseev wrote:
>> I wonder if get_bytes() and set_bytes() will behave differently
>> on little-endian vs big-endian systems?
> No, the returned value will not depend on the CPU endiness. Current
> implementation uses big-endian / network order which in my
On Wed, Aug 14, 2024, at 13:01, Aleksander Alekseev wrote:
> The proposed patch adds get_bytes() and set_bytes() functions. The
> semantics is similar to get_byte() and set_byte() we already have but
> the functions operate with bigints rather than bytes and the user can
> specify the size of the i
On Tue, Aug 13, 2024, at 13:01, Joel Jacobson wrote:
> I think this is acceptable, since it produces more correct results.
In addition, I've traced the rscale_adjustment -15 mul_var() calls to originate
from numeric_exp() and numeric_power(), so I thought it would be good to
brute-fo
On Tue, Aug 13, 2024, at 12:23, Dean Rasheed wrote:
> On Tue, 13 Aug 2024 at 08:49, Joel Jacobson wrote:
>>
>> I reran the tests and v5 produces much fewer diffs than v4.
>> Not sure if the remaining ones are problematic or not.
...
>
> Yes, that's exactly the s
On Tue, Aug 13, 2024, at 09:49, Joel Jacobson wrote:
> I reran the tests and v5 produces much fewer diffs than v4.
> Not sure if the remaining ones are problematic or not.
Attaching scripts if needed.
Regards,
Joel#!/bin/bash
git reset --hard && \
{
patch -p1 < ~/numeric
On Tue, Aug 13, 2024, at 00:56, Dean Rasheed wrote:
> On Mon, 12 Aug 2024 at 16:17, Joel Jacobson wrote:
>>
>> On Mon, Aug 12, 2024, at 17:14, Joel Jacobson wrote:
>> > The case found with the smallest rscale adjustment was th
On Mon, Aug 12, 2024, at 17:14, Joel Jacobson wrote:
> The case found with the smallest rscale adjustment was this one:
> -[ RECORD 1 ]--+
> var1 | 0.9873307197037692
> var2 | 0.426697279270850
> rscale_ad
On Mon, Aug 12, 2024, at 12:47, Joel Jacobson wrote:
>> 2). Attempt to fix the formulae incorporating maxdigits mentioned
>> above. This part really made my brain hurt, and I'm still not quite
>> sure that I've got it right. In particular, it needs double-checking
>&
On Sun, Aug 11, 2024, at 22:04, Joel Jacobson wrote:
>> Attachments:
>> * v4-0001-Extend-mul_var_short-to-5-and-6-digit-inputs.patch
>> * v4-0002-Optimise-numeric-multiplication-using-base-NBASE-.patch
>
> I've reviewed and tested both patches and think they are
On Tue, Aug 6, 2024, at 13:52, Dean Rasheed wrote:
> On Mon, 5 Aug 2024 at 13:34, Joel Jacobson wrote:
>>
>> Noted from 5e1f3b9eb:
>> "While it adds some space on 32-bit machines, we aren't optimizing for that
>> case anymore."
>>
>> In this
On Mon, Aug 5, 2024, at 14:24, Aleksander Alekseev wrote:
>> Could we add a text message that is displayed to a user,
>> when compiling PostgreSQL on a 32-bit platform?
>
> What would be actionable items depending on the results? Option A:
> someone claims to use PostgreSQL on 32-bit hardware. Opti
On Tue, Jul 30, 2024, at 00:31, Tom Lane wrote:
> Dean Rasheed writes:
>> On Mon, 29 Jul 2024 at 21:39, Joel Jacobson wrote:
>>> I think it's non-obvious if the separate code paths for 32-bit and 64-bit,
>>> using `#if SIZEOF_DATUM < 8`, to get *fast* 32-bit
On Tue, Jul 30, 2024, at 11:06, Aleksander Alekseev wrote:
> Hi Joel,
>
> Here are my two cents.
>
>> 1. Who are the current users of 32-bit PostgreSQL?
>
> Pretty much any embedded system that uses just a few GB of memory may
> win from using a 32-bit processor (not necessarily in terms of
> perfo
On Tue, Jul 30, 2024, at 09:25, Heikki Linnakangas wrote:
> On 29/07/2024 23:40, Joel Jacobson wrote:
>> To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with
>> separate 32-bit and 64-bit code paths is worthwhile to maintain performance
>> for bo
Hello hackers,
I would like your help to collectively try to answer these three questions:
1. Who are the current users of 32-bit PostgreSQL?
2. Among these users, how many are upgrading to new major versions?
3. For how many of these users is performance critical?
This came up during ongoing
1 - 100 of 526 matches
Mail list logo
