+0 vote, as I've always interpreted it the way Bruce & Tom
> said upthread, but if we want to change it I can write a patch.
The thing I don't like about 00:00:00 is that it is a lot of information
to say "the start of the day", while I assumed midnight was clear on
that.
On Thu, Jul 11, 2019 at 09:34:58AM +0100, David Harper wrote:
> > One really simple way to make it shorter is to say "00:00", leaving
> > out the seconds.
>
> That’s a good solution. It removes the long-standing ambiguity without
> looking too ugly.
OK, how is t
specify where
postgresql.conf is. Are you saying that doesn't work. Can you show us
the file paths, and the errors you see?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
E STATISTICS example as
city/state, and not state/city?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, Aug 28, 2019 at 08:25:41PM +0200, Tomas Vondra wrote:
> On Wed, Aug 28, 2019 at 12:22:38PM -0400, Bruce Momjian wrote:
> > If this is so, why don't we show the CREATE STATISTICS example as
> > city/state, and not state/city?
>
> Yes, we deduplicate the attribute
so if we're
> going to document anything it should be the latter not the former.
OK, sure. I was just basing the release notes on this commit text:
Add a note suggesting that oids in forks should be assigned in the
9000- range.
I was looking to see information that was
On Wed, Sep 11, 2019 at 06:15:22PM -0300, Alvaro Herrera wrote:
> On 2019-Aug-30, Bruce Momjian wrote:
>
> > OK, how is this patch? I didn't mention psql since I think everyone
> > expects psql to show all information about tables and indexes.
>
> Why would you c
On Thu, Sep 26, 2019 at 05:17:55PM -0300, Alvaro Herrera wrote:
> On 2019-Sep-26, Bruce Momjian wrote:
>
> > On Wed, Sep 11, 2019 at 06:15:22PM -0300, Alvaro Herrera wrote:
> > > On 2019-Aug-30, Bruce Momjian wrote:
> > >
> > > > OK, how is this p
On Thu, Sep 26, 2019 at 11:03:54PM +0200, Tomas Vondra wrote:
> On Thu, Sep 26, 2019 at 04:20:59PM -0400, Bruce Momjian wrote:
> > Uh, people normally list things in defined order, so you would usually
> > not list them in non-defined order unless there is a purpose. Doing
&
On Wed, Sep 4, 2019 at 02:43:15AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-08-30 22:44:53 -0400, Bruce Momjian wrote:
> > On Fri, Aug 30, 2019 at 12:35:09PM -0400, Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > Hmm. I wonder if this item really
ke indexing a coalesce
> function, if scans are not the reason for the index, but the uniqueness
> constraint.
I did write a blog entry about this:
https://momjian.us/main/blogs/pgblog/2017.html#April_3_2017
Does that help?
--
Bruce Momjian http://momjian.u
t; local time zones.
>
> This example would have totally changed how I would have dealt with many
> issues in my software. But since the example did not exist I had no idea I
> could have went down this path.
I did improve the AT TIME ZONE docs in 2018:
commit dd6073f22a
e improved the text with the attached patch. I
also clarified the asynchronous case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roma
r where still applies.
Uh, we are going to need for committers to handle this issue since it is
unlikely we can research email signatures when writing the release
notes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ente
the link for vacuumdb
> went --- I think Bruce's usual practice is to put a only
> on the first reference to a program or function, when there are
> several close together.
Yes, that is true --- the link is added to the first mention of the term
in that section.
> Thanks for th
e the procedure's defining block, or an inner block) then that
> block's executabe section must not issue "commit". Doing so causes a
> run-time error.
Uh, that's a good point since you are in a subtransaction at that point.
What error do you get?
--
Bruce
eds a doc patch.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, Sep 30, 2019 at 12:05:07PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Our current docs have this text for PREPARE:
> >Prepared statements can use generic plans rather than re-planning
> >with each set of supplied EXECUTE values. Th
ountry uses text, another number, ...)
> >
> > Yeah, doesn't seem worth adding.
> >
>
> OK.
Patch applied through PG 12.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am,
too, i.e., more than one
master. Multi-active seems the most logical, or active-active, but then
active-replica seems odd because it suggests the repica is not active,
i.e. does nothing. Is no clear logical terminology possible?
--
Bruce Momjian http://momjian.us
EnterpriseDB
letely agree. I have applied the attached patch to all supported
doc versions to move the mention of log_min_error_statement to a more
logical location. Thanks for the report.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
rg/docs/current/static/gin-extensibility.html
Can you please retest? Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
setDateTime instances will have be in UTC
> > (have offset 0)."
> > I suspect that it was supposed to read: "will be".
>
> You'd need to report this to the JDBC project --- this list is just
> for documentation issues in core Postgres.
Yes, please email pg
On Mon, Oct 7, 2019 at 10:49:54AM +1300, Mike Taves wrote:
> On Sat, 5 Oct 2019 at 10:57, Bruce Momjian wrote:
> > With master/standby-replica-slave, it is clear what multi-master is, and
> > what master/replica is. If you start using active-active, is it
> > active/replic
On Thu, Jul 11, 2019 at 10:42:35AM -0400, Bruce Momjian wrote:
> On Thu, Jul 11, 2019 at 09:34:58AM +0100, David Harper wrote:
> > > One really simple way to make it shorter is to say "00:00", leaving
> > > out the seconds.
> >
> > That’s a good soluti
On Sat, Sep 28, 2019 at 09:47:40AM -0400, Bruce Momjian wrote:
> On Sun, Sep 15, 2019 at 04:37:18PM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page:
> > https://www.postgresql.org/docs/11/different
an index on an expression nor include a WHERE
> clause".
Yes, you are right that the wording is awkward, and has been that way at
least back to 9.4, so I have patched it back through that release;
patch attached. Thanks for the report.
--
Bruce Momjian http://momjian.us
En
that. Bruce, why not adding an item
> about that in the "Migration to Version 12" section? Was that
> intentionally left out?
My reading of the commit message is that the error messages will just be
more helpful now, not that some things would now error that use to be
ignore
, I am wondering if it is just too details for our docs. Can you
think of some text and its location?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, Oct 30, 2019 at 01:29:48PM +0900, Michael Paquier wrote:
> On Wed, Oct 23, 2019 at 10:05:44PM -0400, Bruce Momjian wrote:
> > My reading of the commit message is that the error messages will just be
> > more helpful now, not that some things would now error that use to be
not added to the release notes, and I can't even find where the
restriction is mentioned.
How should this be improved?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am,
specify any
units, the integer is in milliseconds. I am not sure how to improve
that.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, Nov 5, 2019 at 01:27:16PM +0900, Michael Paquier wrote:
> On Mon, Nov 04, 2019 at 09:52:34PM -0500, Bruce Momjian wrote:
> > The default _value_ is 60 seconds, and we use the 's' to specify
> > seconds. What the comment is saying is that if you _don't_ spec
On Tue, Oct 29, 2019 at 02:00:38PM +0200, Tuomas Leikola wrote:
> On Thu, Oct 24, 2019 at 5:31 PM Bruce Momjian wrote:
>
> Uh, I am wondering if it is just too details for our docs. Can you
> think of some text and its location?
>
>
>
> "Unique indexe
m all look like that.
Thanks for applying the improvement in your patch cfb7559083. I was
torn between it being a minor issue and not wanting to devote a new
sentence about it, which is why I awkwardly used parentheses.
--
Bruce Momjian http://momjian.us
EnterpriseDB
. I have fixed it in all supported versions, patch
attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
dif
89ae5a31b86fa => bad: processs
> 2a4d96e..a386942 master -> origin/master
> 4b5e58b86e3b09daa7384dbbd0bb4cacbd9bd7c6 => ok
Thank you so much for the correction, fixed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
ed) Ranges'?
Uh, yeah, those paragraphs need help. You are right that the concept of
infinity in ranges is differnt than the range element type's possible
values of infinity, if it supports it, and the docs are unclear on that.
I have made an attempt at rewriting the paragraphs to clari
rted to inclusive
> But then:
>[,] is automatically converted to (,)
>
> which one is correct?
My mistake. Thanks for finding that. Updated patch attached, plus I
improved the second paragraph.
--
Bruce Momjian http://momjian.us
EnterpriseDB
much work it would take to allow that, but it seems like it
is a valid requite, and if so, I can add it to the TODO list.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
ERROR: syntax error at or near "COPY"
LINE 1: EXPLAIN COPY test FROM STDIN;
^
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
OF
^
I think the best we can do is to mention that IMMUTABLE functions mean
pure, but I am not sure there is even enough demand for that, vs.
confusing people.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.co
w
> > for RETURNING". Becuase, as I have described at first letter, without
> > this the RETURNING rows **does not correspond actually deleted data**
>
> > Thank you.
I have added a TODO item:
Allow DELETE triggers to modify rows, for use by RETURNING
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
x27;t enough to suggest a better alternative however).
I am thinking "pristine" would be a good word here.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote:
> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
> > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am
> > >> not sure how much work it would take to allow that, but i
On Wed, Nov 6, 2019 at 04:41:10PM +0900, Michael Paquier wrote:
> On Tue, Nov 05, 2019 at 10:21:38AM -0500, Bruce Momjian wrote:
> > Ugh, the "if no unit specified" is true of all the settings. Should we
> > make that clearer in a more central location.
>
> Hmm
On Thu, Nov 7, 2019 at 06:50:10PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-07, Bruce Momjian wrote:
>
> > On Thu, Nov 7, 2019 at 07:55:22PM +0100, Daniel Gustafsson wrote:
> > > > On 7 Nov 2019, at 16:03, Alvaro Herrera
> > > > wrote:
>
> >
On Mon, Nov 11, 2019 at 07:00:22PM +0300, Liudmila Mantrova wrote:
>
> > 8 нояб. 2019 г., в 0:26, Bruce Momjian написал(а):
> >
> > First, notice "only", which was missing from the later sentence:
> >
> >For INSERT and UPDATE
> >operati
ere I can read it in
> > depth.
>
> That cannot be answered without knowing the exact statements and the
> table definitions.
I wonder if it is the overhead of rewriting all the rows to set the
per-row HEAP_XMIN_COMMITTED bit. Unfortunately, I don't know a way to
test this hypo
Instead the insert succeeded with id = 4.
>
> I stumbled on this when trying to reset a test DB to all sequences starting
> at 1, and finding that there was one the had somehow gotten a start value of
> 6. I would have expected that 'restart 1' did just that, with no
> complications
box below
> the table.
>
> If I misunderstood what you meant, please be more specific.
Would adding more doc places where we set the session language to
English help here, rather than doing it in the function calls?
--
Bruce Momjian http://momjian.us
EnterpriseDB
ings associated with that server. Grantees may also use the
> foreign
> + server as a connection name in .
>
>
>
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
here in that sentence is the documentation talking about columns in
> > the file, only columns in the table.
> >
> > But if you got it wrong, maybe a clarification would be a good idea.
>
> I think it better to have more details to avoid confusion.
How is the attached pat
e
> to a file column by position (so the number of columns listed must match
> the number of columns in the file).
>
>
>
>
> +1
OK, how is this?
--
Bruce Momjian http://momjian.us
EnterpriseDB
tence is relative to the table columns though so "receive" seems like the
> better fit. Minor point overall though.
OK, this wording is obviously harder than I thought. Updated patch
attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
ecuted.
and in SET TRANSACTION:
If the isolation level, read/write mode, or deferrable mode is
specified, the new transaction has those characteristics, as if SET
TRANSACTION (SET_TRANSACTION(7)) was executed.
Is "has those characteristics" unclear?
--
Bruce
On Fri, Dec 20, 2019 at 09:45:35AM -0700, David G. Johnston wrote:
> On Fri, Dec 20, 2019 at 9:21 AM Tom Lane wrote:
>
> Bruce Momjian writes:
> > OK, this wording is obviously harder than I thought. Updated patch
> > attached.
>
> That one wo
t; 2) what if I have added Keys and Constraints, are they checked later? Means
> loading is shown completed but in background it's creating indices/checking
> constraints.
> 3) Can it be the reason that some other process(which?) is running in
> background during query
e/myname/pgsql/bin, it
> return bash: initdb: command not found The others are like this. It must
> be /home/myname/pgsql/bin/initdb -D /home/myname/pgsql/data.
This is related to your PATH environment variable setting and not
something we document.
--
Bruce Momjian http://m
gt;
> Hi!
> At first I want to thank your for this wonderful software!
> I'm reading pg_basebackup page now and don't see two important section:
> 1) Restoring backup
> 2) Difference with another backup utilities from postgre team
>
> Regards, Semyon.
--
Bruce Mom
ted to wait event profiles here:
> https://www.postgresql.org/docs/devel/monitoring.html
Agreed, it probably should be in the official docs.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Dec 19, 2019 at 03:54:44PM -0500, Jeff Janes wrote:
>
>
> On Thu, Dec 19, 2019 at 11:43 AM Bruce Momjian wrote:
>
> On Wed, Nov 27, 2019 at 11:33:03AM -0500, Jeff Janes wrote:
> > I think that the permissions around the usage of foreign server names as
>
Good points. I have developed the attached documentation patch which
includes your ideas.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Rom
On Wed, Nov 6, 2019 at 08:33:28AM -0500, Bruce Momjian wrote:
> On Wed, Nov 6, 2019 at 12:15:17PM +0200, Eugen Konkov wrote:
> > !Specifying a missing bound as exclusive is automatically converted
> > !to inclusive, e.g., [,] is automatically converted
> > !to
On Tue, Nov 5, 2019 at 12:13:06PM -0500, Bruce Momjian wrote:
> On Tue, Oct 29, 2019 at 02:00:38PM +0200, Tuomas Leikola wrote:
> > On Thu, Oct 24, 2019 at 5:31 PM Bruce Momjian wrote:
> >
> > Uh, I am wondering if it is just too details for our docs. Can you
> >
the output? Thanks. Also, which
Postgres version?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
saction Management" requires "Autocommit" to
> be ON. Otherwise you get an error.
Uh, you can only turn off autocommit on the client side, like psql, not
in the server. What commands are you issuing and what error are you
sseing?
--
Bruce Momjian http://momjian.us
On Tue, Jan 7, 2020 at 11:46:31AM +0100, Laurenz Albe wrote:
> On Fri, 2019-12-27 at 12:16 -0500, Bruce Momjian wrote:
> > On Fri, Dec 27, 2019 at 05:44:10AM +, PG Doc comments form wrote:
> > > The following documentation comment has been logged on the website:
> &
fault-roles.html
> which will now be broken, like from here?:
I talked to Stephen on the phone and he is going to fix the doc areas I
missed, and add some C comments. :-) Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
h. Yes, someone is
> interested in this, to contact me. Thank you.
Great. I didn't realize we had no Spanish version, but a check on our
website doesn't show any Spanish version:
https://www.postgresql.org/docs/
I am sure there is a huge need for this.
--
Bruce Mom
running and what does the failure look like?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
e would be improved by them),
> but I'm not sure about adding them to every single keyword of every
> single reference page. Is that really useful?
It would be helpful if the release notes could point to specific
tables in the docs, rather than just sections.
--
Bruce Momjian
e could modify the code so that we allow SELECT DATE_TRUNC('week',
INTERVAL '') to work if there is no month component, since interval is
made up of months, days, and time. However, this would mean the
function would work with some interval values, and not others. Is that
an i
data.
Uh, most people who use initdb don't care about pg_controldata, but if
you are studying pg_controldata, you should know that initdb created it.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I
UNIX varieties, there is no
> specific content for Windows.
>
> I am happy to help develop solutions for any of the comments I send out.
There is no question that our tutorials and novice stuff is lacking. We
are very good with reference material.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
gt; thought of as "prefined roles", and note they will be called this from Pg13.
Usually when I apply "wording" doc patches to head only, someone
complains that it should be backpatched, so I did that in this case. If
we want to change that idea, we need to agree on the criter
On Mon, Jan 20, 2020 at 06:45:16PM +, Simon Riggs wrote:
> On Mon, 20 Jan 2020 at 16:03, Bruce Momjian wrote:
> Usually when I apply "wording" doc patches to head only, someone
> complains that it should be backpatched, so I did that in this case. If
> we wa
products/6-postgresql-extensions/
> In section about: pg_track_settings
> look for: that me must called
> I'm not one native speaker thus I'm sorry if I took your attention for
> nothing, but is this really a phrase?
> Thanks
This requires a change to our website, so I am
On Tue, Jan 21, 2020 at 10:06:43AM +0100, Laurenz Albe wrote:
> On Mon, 2020-01-20 at 17:13 -0500, Bruce Momjian wrote:
> > Well, I am renaming the documentation label for the feature. Is that
> > different than wording? I guess I can see that. If everyone agrees I
> > can
and no clarity on what this is missing even in master, I will
revert this patch in all branches soon. I think everyone agrees the new
documentation title is better, but we don't want to break things or add
inconsistency to do it.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
7;re
> worried about breaking something right before release.
Folks, is it Thursday. Can we revert this and return to it when we are
not rushed? Alternatively, can someone who controls all the moving
parts, like redirects and Stephen's patch additions take ownership of
this issue, with
; website redirect stuff working so that we can make this change in a
> future release.
OK, thanks everyone.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
gt; both int and numeric types to double.
> The best would be to explain this behaivior of operators like it was done
> for mathematical functions.
Uh, how does this relate to bitwise operators? Why would we mention
type changes for things like exponentiation in the bitwise operator
docu
x27;;
relname
---
pg_authid
pg_subscription
pg_database
pg_db_role_setting
pg_tablespace
pg_auth_members
pg_shdepend
pg_shdescription
pg_replication_origin
pg_shseclabel
at I did do was to mention that row-level locks are released in a
similar way to table-level locks.
Patch attached.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
an btree because the hashes are much shorter.
Expression indexes can also help.
What is your use-case for indexing very long values?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once
(logdate);
I have developed the attached patch to clarify which definition to use.
I am not sure if more extensive changes are needed.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so
bigint
) PARTITION BY LIST (left(lower(name), 1));
CREATE TABLE cities_ab
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b');
Is that sufficient?
--
Bruce Momjian https://momjian.us
level ability to check which functions
require super-user rights. It is buried in the C code.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Other times I used a tool to remove the newlines from the
output. I think you should just use the existing Postgres SQL string
functions to remove the newlines.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
SELECT FROM or INSERT INTO ... VALUES. You can run
tests to prove it.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
IT 10;
>
> Example Results:
> Current Query returns 1 row with buffer count summed for 3 tables:
> relname buffers
> tab1 72401
>
> Modified Query:
> schema_name relname buffers
> schema1 tab11883
> schema2 tab169961
> schema
lans
is calculated. Then a generic plan is created and its estimated
cost is compared to the average custom-plan cost. Subsequent
executions use the generic plan if its cost is not so much higher
than the average custom-plan cost as to make repeated replanning
e
-------
pg_toast_36526
pg_toast_36526_index
test
pg_sYYtistic
I didn't think it was worth documenting this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
4 | 1
3 | 4 | 1
1 | 5 | 2
2 | 5 | 2
3 | 5 | 2
1 | 6 | 3
2 | 6 | 3
3 | 6 | 3
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
+ A
gt;pgdata);
This web page explains the difference well, i.e., "cannot" is present
tens, "could not" is past tense:
https://www.englishforums.com/English/CannotVsCouldNot/bhprvk/post.htm
Is there any sense that we should have more consistency in our message
wording?
--
On Thu, Mar 19, 2020 at 12:07:35PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > We use "cannot" and "could not" quite often in source code and error
> > messages:
>
> Yup.
>
> > Is there any sense that we should have more consistency
cost docs unclear or not have enough
visibility:
https://www.postgresql.org/docs/12/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
Storage that has a low random read cost relative to sequential, e.g.
solid-state drives, might also be better modeled with
xample missed dots:
> > ... m.id = d.id AND m.id = 12;
>
> This one is actually valid as well, as long as both relations don't
> use the same column names, but I can see your point to add the aliases
> to the quals of the WHERE clause to bring more clarity.
Agreed, a
On Thu, Mar 5, 2020 at 08:03:19PM -0700, Sergei Agalakov wrote:
> On 3/5/2020 7:29 PM, Bruce Momjian wrote:
> > On Wed, Jan 29, 2020 at 07:35:18PM +, PG Doc comments form wrote:
> > > Multiplication preserves data type, exponentiation silently converts
> > >
301 - 400 of 774 matches
Mail list logo
