> Aha! So it's likely that by listing the PK column name in the list of
> columns to be inserted was what caused the problem? No need to specify
> DEFAULT for it?
>
There's no need to specify the column if it has a default value, but
specifying it did not cause the issue that you saw.
On Wed, Jun 5, 2024 at 4:23 AM Sam Kidman wrote:
> We get very poor performance in the staging environment after this
> restore takes place - after some usage it seems to get better perhaps
> because of caching.
>
This is due to the way that RDS restores snapshots.
>From the docs
>(https://doc
On Sat, May 13, 2023, 3:25 AM Kirk Wolak wrote:
> Does this imply SQL SYNTAX like:
>
> SHOW CREATE TABLE
> [ INCLUDING { ALL | INDEXES | SEQUENCES | ??? }]
> [EXCLUDING { PK | FK | COMMENTS | STORAGE | } ]
> [FOR {V11 | V12 | V13 | V14 | V15 }] ??
> ?
>
Personally, I would expect a funct
On Wed, Apr 19, 2023 at 2:19 PM Bryn Llewellyn wrote:
> This tip
>
> «
> It is good practice to create a role that has the CREATEDB and CREATEROLE
> privileges, but is not a superuser, and then use this role for all routine
> management of databases and roles. This approach avoids the dangers of
On Tue, Mar 28, 2023 at 10:55 AM Peter J. Holzer wrote:
>
>
> The configuration includes `use_slots: true` and I can see a slot in
> pg_replication_slots on the leader.
>
> I was under the impression that this would be sufficient to prevent WALs
> from being deleted on the leader before they are
>
>
> How to do this with two tables connected via one foreign key, that is
> explained a dozen times in Stackoverflow. But what if the tree is 50
> tables and 120 foreign key columns?
> It can be done. But probably not manually.
>
> So, as this seems a very usual use-case for normalized data, is t
>
> From a user point of view, can also be seen as a "regression",
> when an observable property of the system changes to a new
> different / incompatible way, to some extent. I'm not saying it is,
> still it is a change one discovers too late, creates pain to some,
> and is both worth reporting an
>
>
>
> *sudo systemctl stop postgresql**sudo *
> *systemctl start postgresql**pg_ctl reload -D /etc/postgresql/11/main/*
>
> (I know that I could've used "systemctl restart ".) Like I said elsewhere,
> the "reload" seems to be superfluous. But it costs nothing to do it.
>
>
Actually, you only n
>
> I can now characterize what I'd observed more clearly, thus: only a
> bootstrap super user (as defined above) can start a session without
> mentioning the name of the database to which to connect and the name of the
> within-cluster role to connect as—and without supplying a password. And it
>
I say this only to emphasize that there are always things that are critical
> that are elided in a testcase that tries to be minimal.
>
> So it seems that there's something critical about my env that I'm failing
> to tell you all. But what can it be?
>
>
Removing permissions also works for me. In
- New versions are created for all rows, even if the data is identical.
> This quickly fills up the WAL and puts unnecessary load on the tablespace
> drives.
>
> - If the conflict target is not the serial column, the sequence backing
> the serial column gets incremented for every row. This quickly
I think this explains the situation well:
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN
On Tue, Jun 14, 2022 at 11:59 AM Dirschel, Steve <
steve.dirsc...@thomsonreuters.com> wrote:
> We are in the process of migrating from Oracle to Postgres and the
> following query does muc
>
> Doesn't this usually happen if q.id contains NULL. That is as per ANSI
> standard.
>
>
Yes, there's a good description of this here:
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN
It would be better to use NOT EXISTS:
select count(*) from snapshotlist where NOT EXISTS (SELE
>
> We found out because we are monitoring long running queries, and saw it
> had been running for a month before the restart yesterday.
> I just queried pg_stat_activity and it seems to be running since then.
>
> taimusz=# SELECT pid, query_start, usename, left(query,70)
> FROM pg_stat_activity
>
>
>
> Could there be some tuning option in PostgreSQL to make queries via
> foreign tables faster (e.g. I heard about option fetch_size)?
>
fetch_size can make a difference, but it won't change a query that takes
hours into a query that takes seconds. The default is likely too low,
though.
Have
On Sat, Jan 9, 2021 at 9:22 AM Markhof, Ingolf <
ingolf.mark...@de.verizon.com> wrote:
> Tom, all,
>
> when I change a tables column name in Oracle SQL , SQLdeveloper (a SQL
> client) marks views that refer to the table using the old column name as
> erroneous. So, I can easily identify these case
It looks like you are using now() fairly often in that query. That would,
of course, give different results in different transactions, but it could
also give different results if a) the things you are comparing now() to are
timestamp without time zone and b) the session time zone of the user doing
Unfortunately, return query will never use parallel workers. See:
https://stackoverflow.com/q/58079898/895640 and
https://www.postgresql.org/message-id/16040-eaacad11fecfb...@postgresql.org
On Sat, Mar 21, 2020 at 1:59 PM Alastair McKinley <
a.mckin...@analyticsengines.com> wrote:
> Hi Adrian,
>
Hello all,
We have a data warehouse (postgres 11.5, on centos 7) that contains
many instances of the following structure:
- table_a
- table_b
- a view that selects everything from either table_a or table_b
All external queries select from the view, so we can rebuild the table that
isn't e
19 matches
Mail list logo
