.postgresql.org/docs/current/runtime-config-query.html#GUC-RANDOM-PAGE-COST
regards
Marcos
Em qua., 5 de fev. de 2025 às 20:59, Peter Smith
escreveu:
> On Thu, Feb 6, 2025 at 8:08 AM Marcos Pegoraro wrote:
> >
> > Reading DOCs sometimes is boring because you want to know only
Em qui., 6 de fev. de 2025 às 12:32, Greg Sabino Mullane
escreveu:
> That seems a somewhat arbitrary goal for us to optimize for.
>
well, my goal was to standardize these values. As examples of
non standardization you have ...
"The default is typically 100 connections".
Tipically ? Is it 100 or
>
> Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
Section nullvalues-filtering you are showing filtering with equal and not
equal. Wouldn't it be better if you show just one of them and the other
using DISTINCT FROM, which would get different r
Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> I got rid of the row counts on the examples.
>
Cool, I would love to get rid all of them, like I proposed on [1].
> When I finalize the examples I'm probably going to \pset null .
>
Yes, much better
Em qui., 21 de nov. de 2024 às 11:42, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
>
> I'm not following your train of thought here. Since null == null in
> json-land there isn't a need for or concept of "is distinct from". We tend
> to not expend space on pointing out things that d
About JSONB_PATH, you said that "JSON null value is considered equal to
other JSON null values", but didn't say anything about IS DISTINCT FROM at
jsonb_path level. Wouldn't be good to mention something about it ?
select '{1,2}'::integer[] is distinct from null::integer[]
select jsonb_path_exists(
Em qui., 21 de nov. de 2024 às 12:02, Marcos Pegoraro
escreveu:
Well, all comparisons with JSONs runs differently with null values, so
maybe an example would help
select f1 = f2 "JS Object Equal - Right",
f1->'a' = f2->'a' "JS Value Equal - Right
Em qui., 21 de nov. de 2024 às 12:04, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
Typo in NuLl, mixed upper and lower case.
SELECT
NULL AS "Literal Null Value",
pg_typeof(null) AS "Type of Null",
pg_typeof(NuLl::text) AS "Type of Cast null",
cast(null as text) AS "Ca
There is no rule of when the number of records at the end of the lists
should be shown or not
Sometimes we show that line "(4 rows)", but sometimes not.
Should we have a standard for it ? Should we add them all or remove them
all ?
I think they are useless. Or maybe shown when no rows are returned.
Em dom., 22 de dez. de 2024 às 12:02, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
You have detailed IS NULL and IS NOT NULL predicates but not mention their
counterparts ISNULL and NOTNULL, wouldn't it be good to explain that too ?
Maybe pointing to its page "functions-comparison"
r
Em qua., 8 de jan. de 2025 às 16:23, Vik Fearing
escreveu:
> This is lying to the planner, and you get to enjoy whatever breaks
> because of it. A function that accesses external data is not immutable;
> it is stable at best.
>
I understand that, but it's not documented, so users can think that
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give
Em sex., 10 de jan. de 2025 às 06:31, Antonin Houska
escreveu:
> Thus I understand Alvaro's objections against VACUUM (FULL, CONCURRENTLY).
>
> Therefore I can imagine adding a new command that acts like VACUUM (FULL,
> CONCURRENTLY), but does not try to be CLUSTER (CONCURRENTL).
>
If VACUUM F
Em ter., 21 de jan. de 2025 às 14:50, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> I have to ask, why do you think this is important?
>
I'm just reading sources, navigating on files history and learning, so
don't be furious with me.
Why is this important ? Well, if that file has a 2014-2
Em ter., 21 de jan. de 2025 às 12:36, Tom Lane escreveu:
> so we prefer to use the same copyright dates as related older files even
> in less
> clear-cut cases.
>
Thank you Tom for your time.
But these numbers seem inaccurate, because there are 1644 copyright strings
but 1521 are 1996-2025. So,
>
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian
> napsal:
>
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
>
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, a
Em sex., 17 de jan. de 2025 às 13:01, Bruce Momjian
escreveu:
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, and
c
Today Amit Langote committed execScan.h and put on its header years from
1996 to 2025. Those years are what exactly ?
This file has 1996, but sometimes is the first commit year of that file,
sometimes is completely unrelated. What is right for it ? Need that to be
adjusted ?
/*
Em dom., 22 de dez. de 2024 às 15:07, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
On section Null-Valued Settings is not easy to understand that "show
example.string" will result in an "ERROR: unrecognized...", that BEGIN or
ROLLBACK does not return anything. So, what do you think ab
>
> On 14.01.2025 22:51, Melanie Plageman wrote:
>
There is a typo on committed vacuumlazy.c file
* If the TID store fills up in phase I, vacuum suspends phase I, proceeds
to
* phases II and II, cleaning up the dead tuples referenced in the current
TID
* store. This empties the TID store resume
Em qua., 19 de mar. de 2025 às 18:14, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Having been in filelist.sgml a bit recently I've noticed that the original
> alphabetical ordering of the entities therein hasn't been adhered to.
> Partly, I suspect, because there is no guidance abo
Em seg., 17 de mar. de 2025 às 15:33, Pavel Stehule
escreveu:
> I was asked for sending a reduced patchset
>
Would be good to explain what this reduced patchset is.
Complete patch contains this and that
Reduced patch contains only this.
Regards
Marcos
Em qua., 26 de mar. de 2025 às 06:50, Dean Rasheed
escreveu:
> OK, thanks. I've updated that comment and committed it.
func.sgml doesn't mention lgamma function, so users will think just gamma
exists, is that correct ?
regards
Marcos
Em qua., 26 de mar. de 2025 às 08:58, Marcos Pegoraro
escreveu:
> func.sgml doesn't mention lgamma function, so users will think just gamma
> exists, is that correct ?
>
Sorry, it's my fault. I didn't read the entire file.
regards
Marcos
Em ter., 1 de abr. de 2025 às 02:00, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
Wouldn't it be good to add the use of parentheses using posix ? It's useful
and rarely documented
substring('Thomas', '...$')
+substring('Email: johnj...@mymail.com, Name: John' from
'@(.
You mentioned fillfactor only on cluster notes, would be good to mention it
on refsynopsisdiv, I think.
+
+ REPACK reclaims storage occupied by dead
+ tuples. Unlike VACUUM, it does so by rewriting the
+ entire contents of the table specified
+ by table_name into a new
disk
- file wit
Em ter., 11 de mar. de 2025 às 16:47, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Since COPY uses \N I figured it was a decent choice. or came
>> to mind too, but there were long compared to 1, 2, and 4 that appear along
>> side it.
>>
> Well, I would use , it doesn't need any ex
Em qui., 13 de mar. de 2025 às 09:17, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> I tried this example all the way back to pg 9.5, and they all end up
> with a single constraint and a single index -- namely, the test_pk
> constraint and corresponding index. There's no second index and n
Em ter., 11 de mar. de 2025 às 17:43, Tom Lane escreveu:
> I think that idea (changing all the docs) is a complete nonstarter
> because people would not understand why the results they get don't
> look like what it says in the docs. Of course, we could fix that
> by changing the factory default
Em ter., 11 de mar. de 2025 às 12:52, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> The markup surrounding the examples is correct now and I decided \N was
> the most useful representation of NULL given that the query data is single
> digit numbers. I really hate the non-readability
CREATE TABLE table_test (
foo text NOT NULL,
CONSTRAINT test_pk PRIMARY KEY (foo),
CONSTRAINT test_uq UNIQUE (foo)
);
building index "pg_toast_29364884_index" on table "pg_toast_29364884"
serially
building index "test_pk" on table "table_test" serially
pg_class has 3 records, table, it
I was deleting thousands of records each time with \gexec, then ...
This one works
select format('delete from table where ID = any(%L::integer[]);',
array_agg(ID)), (ord-1)/1 from (
select * from generate_series(15e2,65e5) with ordinality) x(ID, ord) group
by 2 order by 2;
But it's easier to
Em sex., 4 de abr. de 2025 às 13:13, Maciek Sakrejda
escreveu:
> maciek=# select pg_typeof(1e1)
Correct, this explains that
regards
Marcos
Em sáb., 10 de mai. de 2025 às 21:57, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Constraints can be targeted by “comment on”.
>
So, why not using that COMMENT ON message to raise when that constraint
gets violated ?
A GUC like Constraint_Exception_Returns_MessageOn = {Never | Alw
Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
escreveu:
> I will again ask why this patch set is being reposted when there is no
> plan to apply it to git master
Too bad. I would love to have this functionality, from the user's point of
view there are problems where it would solve them wo
101 - 135 of 135 matches
Mail list logo
