> On Jul 12, 2024, at 06:18, pradeep t wrote:
> Shall I use the Postgresql database for a semantic cache like the Redis
> semantic cache?
If you mean this feature:
https://redis.io/docs/latest/integrate/redisvl/user-guide/semantic-caching/
... there is no direct equivalent in
> On Jul 16, 2024, at 21:45, imndl...@gmx.com wrote:
> Or, does Postgres expect to be able to access any media however it wants
> (i.e., R/w), regardless of the expected access patterns of the data stored
> there?
Well, yes and no.
PostgreSQL will not respond well to having media that is
> On Jul 15, 2024, at 12:06, Sarkar, Subhadeep wrote:
>
> • Does the Community edition of PostgreSQL provide NATIVE active-active high
> availability clustering with objectives of scalability, load balancing and
> high availability without using any extensions or external components or
>
> On Jul 15, 2024, at 12:06, Sarkar, Subhadeep wrote:
>
> • Does the Community edition of PostgreSQL provide NATIVE active-active
> high availability clustering with objectives of scalability, load balancing
> and high availability without using any extensions or external components or
>
> On Jul 8, 2024, at 13:29, Christophe Pettus wrote:
>
>
>
>> On Jul 8, 2024, at 13:25, Laurenz Albe wrote:
>> I didn't test it, but doesn't that allow the member rule to drop objects
>> owned
>> be the role it is a member of?
>
> No, apparent
> On Jul 8, 2024, at 13:25, Laurenz Albe wrote:
> I didn't test it, but doesn't that allow the member rule to drop objects owned
> be the role it is a member of?
No, apparently not.
> On Jul 8, 2024, at 12:58, David G. Johnston
> wrote:
> That scenario is allowed but provides no useful in-server behavior.
That was my conclusion as well. Thanks!
Hi,
This is more curiosity than anything else. In the v16 role system, is there
actually any reason to grant membership in a role to a different role, but with
SET FALSE, INHERIT FALSE, and ADMIN FALSE? Does the role granted membership
gain any ability it didn't have before in that case?
> On Jul 3, 2024, at 13:24, Kent Dorfman wrote:
> Is it SQL standard or postgres specific?
It's not in the SQL standard (at the bottom of each page for each SQL command
is a note regarding its relationship with the SQL standard). Other DBMS
implement something similar, however.
Quick example:
xof=# CREATE TABLE t1 (id SERIAL PRIMARY KEY);
CREATE TABLE
xof=# CREATE TABLE t2 (id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY);
CREATE TABLE
xof=# \d+
List of relations
Schema | Name| Type | Owner | Persistence | Access
> On Jul 3, 2024, at 12:28, Kent Dorfman wrote:
>
> Is there any psql function/command to add a description field to a table or
> view definition in the system?
Allow me to introduce you to my good friend "COMMENT":
https://www.postgresql.org/docs/current/sql-comment.html
> On Jul 2, 2024, at 18:16, Stuart Campbell
> wrote:
>
> My understanding was that under the hood, AWS uses the logical replication
> features that are present in community Postgres. If that's incorrect then I'm
> sorry for the off-topic post.
Yes, but: The idea of a "degraded"
> On Jul 2, 2024, at 17:47, Stuart Campbell
> wrote:
> My question is whether there is some workaround that will let me create
> indexes on a temporary table, and also let me drop the temporary table, in a
> way that doesn't end up "degrading" replication? (Presumably that means
> avoiding
> On Jul 2, 2024, at 15:11, Rich Shepard wrote:
> This data set is the
> only one I've encountered that has a very few multiple email addresses for a
> person.
That's pretty common out in the world. Just pulling a small dataset I have
available, 4+ email addresses per customer happen
> On Jul 2, 2024, at 14:57, Rich Shepard wrote:
> Using text rather than varchar() is a good suggestion.
To be clear, I wasn't suggesting stuffing them all into a text column with a
delimiter, but storing them in a text *array* field, each email address one
component of the array.
> On Jul 2, 2024, at 14:47, Rich Shepard wrote:
> Is there a way
> to accommodate multiple email addresses other than entering both with a
> forward slash separating them in the varchar(64) email address column?
If you are absolutely 100% sure there will never be any metadata associated
with
> On Jun 10, 2024, at 18:10, Rich Shepard wrote:
> Thanks, Christophe. Is there a way to reset the sequence to the maximum
> number +1? I don't recall seeing this in the postgres docs but will look
> again.
The sequence functions are documented here:
> On Jun 10, 2024, at 15:57, Rich Shepard wrote:
> When I tried inserting new rows in the companies table psql told me that PK
> value 2310 already existed. Selecting max(PK) returned 2341. When entering
> multiple new rows is there a way to ignore gaps?
Strictly speaking, the sequence
> On May 20, 2024, at 08:49, PetSerAl wrote:
> Basically, you need application cooperation to make
> consistent live database backup.
If it is critical that you have a completely consistent backup as of a
particular point in time, and you are not concerned about restoring to a
different
> On May 19, 2024, at 11:30, Rich Shepard wrote:
> That's a good idea; I can use a predicate to identify the rows to update.
> That would be shorter than a long, comma-separated list.
Of course, you can probably also shorten the query to:
UPDATE people SET active=true WHERE ...
> On May 19, 2024, at 09:54, Rich Shepard wrote:
>
> Specifically, in the 'people' table I want to change the column 'active'
> from false to true for 457 specific person_id row numbers.
UPDATE people SET active=true WHERE id IN (...);
The ... can either be an explicit list of the ids, or a
> On May 13, 2024, at 11:26, Adrian Klaver wrote:
> May not induce the error unless there are parallel workers involved.
Indeed. I'll see about pulling together a test case that forces that.
> On May 13, 2024, at 11:17, Tom Lane wrote:
> What's causing that I can't say. It doesn't look like we log the
> errno anywhere when failing to read a zone file :-(
File descriptor exhaustion? (Of course, that would mean something somewhere is
leaking them, which is another problem.)
> On May 13, 2024, at 11:07, Adrian Klaver wrote:
>
>
> What does pg_config --configure show for '--with-system-tzdata' ?
It's a local compile, and was built without that.
As an experiment, I'm just pounding the server with a single connection doing
nothing but SET TIMEZONEs repeatedly.
> On May 13, 2024, at 10:58, Adrian Klaver wrote:
>
> You sure the timezone file did not get changed under the connection?
Yes (at least, nothing happened on the system that would indicate that). The
system wasn't touched during the execution (and, as noted, it worked after as
well as
> On May 13, 2024, at 10:53, Erik Wienhold wrote:
> Can you trigger that error with:
>
> SET timezone = 'UTC';
No, that works correctly:
psql (16.3)
Type "help" for help.
df=> SET timezone = 'UTC';
SET
The error popped up during a long-running connection that had issued that SET
many
> On May 13, 2024, at 10:48, Adrian Klaver wrote:
> Yes:
>
> https://www.postgresql.org/message-id/5DF49366-10D1-42A4-99BF-F9A7DC3AB0F4%40mailbox.org
>
> Answer:
>
> https://www.postgresql.org/message-id/1273542.1712326418%40sss.pgh.pa.us
Thanks! Similar, but I don't think it's that.
PostgreSQL 16.3 on MacOS Sonoma. A long-running process (which held a
connection open the entire time) failed with:
2024-05-13 09:12:44.719
PDT,"cyan","cyan",35926,"[local]",664214f9.8c56,3,"SELECT",2024-05-13 06:26:17
PDT,3/60,0,ERROR,22023,"invalid value for parameter ""TimeZone"":
> On May 3, 2024, at 20:02, Siddharth Jain wrote:
>
>
> The way I understand this is that if there is a failure in-between, we start
> undoing and reverting the previous operations one by one. But what if there
> is a failure and we are not able to revert an operation. How is that
>
> On Apr 17, 2024, at 10:13, Johnathan Tiamoh wrote:
> I performed an upgrade from postgresql-9.5 to postgresql-14 and the
> performance has degraded drastically.
>
> Please, is they any advice on getting performance back ?
Run:
VACUUM (ANALYZE, VERBOSE);
More seriously (although
> On Apr 8, 2024, at 06:37, Ron Johnson wrote:
>
> Four times, the word "referential_action" is used on this page, but it's
> never mentioned what the possible referential actions are.
They're defined in CREATE TABLE:
https://www.postgresql.org/docs/14/sql-createtable.html
> On Mar 31, 2024, at 09:59, Peter J. Holzer wrote:
> Is this an acceptable performance penalty per API call? If not, is it
> really necessary to check this on every call? Maybe it can be done just
> once per session or once per hour.
It's probably not required to check it every API call.
> On Mar 29, 2024, at 14:16, David Gauthier wrote
> I tried encapsulating the DB name in double quotes (no good), single quotes
> (still no good) escaping with '\' (no good), escaping with ".." (no good).
This is probably more about the string handling in the API you are using than
> On Mar 26, 2024, at 22:30, Siraj G wrote:
> I am from Oracle background. In Oracle, we grant select_catalog_role or
> select any dictionary role to users who want to study performance data. I am
> trying to get similar information on the roles or privileges in PgSQL that we
> might want
> On Mar 25, 2024, at 07:20, Daniel Gustafsson wrote:
>
>> On 25 Mar 2024, at 15:09, Tom Lane wrote:
>
>> My initial reaction is that we should warn only when the command
>> is a complete no-op, that is none of the mentioned privileges
>> matched.
>
> That's my gut reaction too,
I think
Right now, if you do a REVOKE that doesn't actually revoke anything, it works
silently. This can be a bit of a foot-gun. For example:
CREATE FUNCTION f() RETURNS int as $$ SELECT 1; $$ LANGUAGE sql;
REVOKE EXECUTE ON FUNCTION f() FROM lowpriv;
Naively, it might be expected
> On Mar 25, 2024, at 02:50, Thiemo Kellner wrote:
> My bad. I was under the impression that the create table statement was an
> atomic process/transaction with all its bells and whistles for constraints
> and keys, instead of a succession of alter statements.
That may be a bit judgmental.
> On Mar 24, 2024, at 09:32, Thiemo Kellner wrote:
> Am 24.03.2024 um 17:15 schrieb Christophe Pettus:
>> I think the point is that it's not really doing anything "silently." You
>> are asking for a PRIMARY KEY constraint on a column, and it's giving it to
On 3/24/24 08:28, Thiemo Kellner wrote:
> Sure, my example has lots more side effect than silently do the right thing.
I think the point is that it's not really doing anything "silently." You are
asking for a PRIMARY KEY constraint on a column, and it's giving it to you.
One of the effects
> On Mar 22, 2024, at 20:55, arun chirappurath wrote:
> I am trying to force query to use indexes using query hints.
PostgreSQL does not have query hints. Enabling index scans using parameters
doesn't *disable* other types of query nodes.
You can disable sequential scans using:
> On Mar 22, 2024, at 09:25, Fred Habash wrote:
>
> Facing an issue where sometimes humans login to a database and run DDL
> statements causing a long locking tree of over 1000 waiters. As a workaround,
> we asked developers to always start their DDL sessions with 'SET lock_timeout
> =
> On Mar 20, 2024, at 09:51, Celia McInnis wrote:
>
> The view is being used in some web query software that multiple people will
> be accessing and the contents of the view depend on what the person is
> querying, so I think that temporary views or tables are a good idea.
There's nothing
> On Mar 19, 2024, at 19:56, Celia McInnis wrote:
>
> Thanks for the suggestion, Steve, but No - when I insert 25:17:07::interval
> into my table I get 01:17:07 into the table - i.e., it replaces 25 hours by
> (25 mod 24) hours or 1 hour, and this is not what I want. I really need the
>
> On Mar 15, 2024, at 03:30, Thiemo Kellner wrote:
> Thanks for the ideas. As I would want to keep it in the database, dblink
> would be the way to go. Maybe, I will create a prodedure that creates a view
> in the monitor schema accessing the respective databases with union all to
>
> On Mar 12, 2024, at 19:27, Adrian Klaver wrote:
>
> Oops?
Oops. Apologies for the mis-forward.
Begin forwarded message:From: Sadie Bella Subject: Fwd: Receipt for PostgreSQL US Invoice #1840Date: March 12, 2024 at 19:13:40 PDTTo: Christophe -- Forwarded message -From: Date: Tue, Mar 12, 2024, 7:07 PMSubject:
> On Mar 12, 2024, at 07:15, Dominique Devienne wrote:
> So is it possible to track the last time a SELECT was performed on some TABLE?
Directly, no. You could periodically sample the various table-level
statistics, and conclude that tables that have had some type of scan since the
last
> On Mar 8, 2024, at 00:53, Matthias Apitz wrote:
> It does not say definitely that for all other versions a dump/restore is
> required.
You cannot just replace the binaries to upgrade from an earlier major version
to 16.X. The release notes use "a dump/restore (is/is not) required" to
> On Mar 7, 2024, at 06:56, Achilleas Mantzios - cloud
> wrote:
> So, I ask, have there been any efforts to bring PL/PGSQL to the terminal?
Strictly speaking, of course, you can use PL/pgSQL from the terminal already:
just use psql, connect to the database, and create and run functions and
> On Mar 6, 2024, at 13:18, Lorusso Domenico wrote:
> So there is a way to automatically generate DDL in the right order?
Standard pg_dump creates files that are in the proper order, although if you
exclusive some tables or schemas from the backup, those might cause errors if
references
> On Mar 3, 2024, at 12:00, Christophe Pettus wrote:
> Remember that dropping the NULL constraint afterwards will require a full
> table read (although not a rewrite).
Sorry, badly put: Adding a NOT NULl constraint afterwards will require a full
table read (although not a rewrite).
> On Mar 3, 2024, at 11:40, yudhi s wrote:
> Thanks for the clarification. In case of adding the column as volatile
> default (like current_timestamp function as default) or say adding NOT NULL
> column with some conditional population of existing values will be a full
> table rewrite. In
> On Mar 3, 2024, at 11:06, yudhi s wrote:
> as the column addition using the traditional "Alter table" command in
> postgres looks to be a full table rewrite
That's not always (or, really, usually) true. Adding a new column in any
recent version of PostgreSQL just alters the system
> On Feb 6, 2024, at 10:11, Ron Johnson wrote:
> Thus, I'd like to exclude reads from "Postgresql JDBC Driver". (Currently, I
> filter that out using "grep -v" in a shell script that runs hourly from cron,
> but I find that unsatisfactory.)
pgAudit doesn't currently include filters by
> On Jan 29, 2024, at 11:39, David Gauthier wrote:
>
> Is there a document which makes recommendations on sizing data buffer cache,
> tuning options which evict old/unused data in mem, and cache fragmentation
> avoidance for a v15.3 DB ?
On any modern system, set shared_buffers to 25% of
> On Jan 29, 2024, at 11:22, Bill Mitchell wrote:
>
> Wondering if any of the other members of this LISTSERV have tried migrating
> their data off of Amazon RDS Aurora Postgres with success.
Any logical-replication based solution (DMS, fivetran, in-core logical
replication) will handle the
> On Jan 24, 2024, at 19:17, Sasmit Utkarsh wrote:
>
> Need your support on understanding advisory locks in Postgresql and what is
> the best practice to have advisory locks and unlocks to work properly when we
> have multiple process forked from single process?
Advisory locks are a shared
> On Dec 25, 2023, at 10:44, Adrian Klaver wrote:
> Functions with same name in different schemas would need to be dealt with.
I think that's the primary use-case (at least, it would be for me), and I don't
see a convenient way of doing that. Even a "get OID of current function"
function
> On Dec 1, 2023, at 09:47, Ping Yao wrote:
> Can someone help me understand why my simple DELETE query is so slow to run?
Based on the plan, you're running PostgreSQL with the Citus extension, and the
delay is in Citus-related code. This is probably a question best directed to
either the
> On Nov 27, 2023, at 10:16, Dominique Devienne wrote:
> Which means you can't do a declarative SQL query for those
> metadata across projects, since you can't do static / non-dynamic SQL across
> schemas.
I'm not sure I understand this. Schemas are just namespaces, and all queries
have
> On Nov 20, 2023, at 13:41, David Gauthier wrote:
> I want the users to be required to provide a value for ssn in the following
> query...
> "select * from huge_view where ssn = '106-91-9930' "
> I never want them to query the view without specifying ssn.
> It has to do with resources and
> On Nov 11, 2023, at 17:20, p...@pfortin.com wrote:
> Actually, it's more eusbtle... I can make it work as "postgres"; but not
> as a RO user (SELECT only):
> An error occurred when executing the SQL command:
> select * from a,b where regexp_replace(a.address,' ','','g') =
>
> On Nov 2, 2023, at 23:26, Kar, Swapnil (TR Technology)
> wrote:
> We want Support users to have no SELECT or DML privilege but only ALTER TABLE
> to perform any troubleshooting in the database.
If a user has no ability to do SELECT or DML, they won't be able to
"troubleshoot" the
> On Oct 26, 2023, at 11:53, Atul Kumar wrote:
>
> Please share the required link having such information in detail, It would be
> more helpful to me.
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
> On Oct 26, 2023, at 11:44, Atul Kumar wrote:
> There is already one line to serve your stated purpose
> local all alltrust
>
>
> That's why I specifically raised this question for below from postgresql
> experts
> hostall all
> On Oct 25, 2023, at 17:21, Pól Ua Laoínecháin wrote:
>
> SELECT (ts, te)::TSTZRANGE FROM test;
That syntax doesn't mean what you probably think it does. (ts, te) defines a
record type with two fields. PostgreSQL constructs that, and then attempts to
apply the cast. There's no
> On Oct 24, 2023, at 11:31, Brad White wrote:
> Are you saying that once I get streaming replication set up, it quits working
> when I reboot the servers once a week?
Not unless the downtime is sufficiently long that the replica can't find the
WAL information it needs. You can avoid this
> On Oct 23, 2023, at 04:45, Achilleas Mantzios - cloud
> wrote:
> I believe this text is false on too many accounts. So, what's the consensus
> about Inheritance in PostgreSQL, I am going to give a talk on it in November
> and I wouldn't like to advertise/promote/teach something that the
> On Oct 16, 2023, at 00:51, Thiemo Kellner wrote:
> Question: Are there plans to provide a feature in PostgreSQL that one can
> have foreign keys for purely documentation purpose - I know, one could use a
> modelling tool and just not implement the FKs, but my reality is, there is
> hardly
> On Sep 20, 2023, at 14:11, veem v wrote:
>
> Does AWS aurora postgres depend on the same vacuuming technology for
> maintaining the transactions?
Yes. Aurora has replaced the PostgreSQL storage engine, but the MVCC part is
largely the same. The issues with vacuuming are largely
> On Aug 22, 2023, at 19:57, Jethro Elmer Sanidad
> wrote:
>
> Hello,
>
> I tried both the 1.5.0 and 2.0.0. Both returned error during 'make' command.
> Please see below:
The API between PostgreSQL and foreign data wrappers has changed significantly
since 9.4. As Tom mentioned, you need
> On Aug 6, 2023, at 18:17, H wrote:
>
> Is there some setting I have to change in the database to have the first SQL
> statement to work or have I run into a possible bug?
The first statement just generates a line of text output that contains the
statement. There's nothing in it that
> On Aug 1, 2023, at 10:13, William Edwards wrote:
> This allows all local users connecting over TCP to access all databases, not
> only the databases that the user is a member of as one might expect.
There's really no notion of a user being "a member of" a database in
PostgreSQL. Users
> On Jul 10, 2023, at 11:54, Bryn Llewellyn wrote:
>
> What is the rationale for supporting what seems to be on its face this
> strange functionality?
It allows you to EXIT or CONTINUE a loop that is not the innermost one, by
naming the label of an outer loop.
One can debate endlessly
> On Jul 10, 2023, at 11:46, DAVID ROTH wrote:
>
> Is there a way to get new.* into a jsonb column?
The to_jsonb() function accepts a row type like NEW.*, and returns a JSONB
object with the keys as column names.
> On Jul 10, 2023, at 11:37, DAVID ROTH wrote:
>
> Thanks for the example. I have a test trigger now that does that but my
> application needs all of the columns.
I'm not quite sure I understanding. Logging NEW.* and OLD.* *does* get all the
columns, without having to specific query to
> On Jul 10, 2023, at 11:29, DAVID ROTH wrote:
>
> I want to use a single trigger function to log multiple tables and the tables
> have different columns. I can get the names of the columns from the catalog.
> But I have not been able to figure out how to get NEW.x when x is not known
>
> On Jul 10, 2023, at 11:20, DAVID ROTH wrote:
>
> In a trigger function, is there a way to get a list of all of the columns in
> the triggering table?
You can get the table that the trigger fired on with TG_TABLE_SCHEMA and
TG_TABLE_NAME, and then query the system catalogs to get a list
A UNIQUE index can have any number of columns, so you can create an index with
all of the appropriate columns listed. This is different from having a UNIQUE
index on each individual column. In the former case, all of the columns
together must be unique; in the latter case, as you mention,
Hi,
> On Jun 12, 2023, at 11:57, Raj Kiran wrote:
> Prokopto is completing our annual vendor review process. Please share your
> most recent SOC II Type 2 report.
The PostgreSQL project isn't SOC2 certified, and will almost certainly never
be. If you require SOC2 compliance, you'll need to
> On Jun 2, 2023, at 17:44, Ron wrote:
> Is this to be expected of such a huge schema?
pg_upgrade time is pretty much proportional to the number of database objects
in the schema, so a much larger schema taking much longer is to be expected.
> On May 22, 2023, at 13:06, Adrian Klaver wrote:
> As I understand TDE whether you can get to the files is not really the point.
> It is that someone/thing can and if they do the files are encrypted. Pretty
> sure RDS is not magical enough to have no access from any source to the file
>
> On May 22, 2023, at 11:02, Tony Xu wrote:
> there are still some shared area between clusters.
That's not quite right. A PostgreSQL cluster (in the traditional sense, which
means one PostgreSQL server handling a particular endpoint) is isolated from
any other clusters on the same
> On May 15, 2023, at 08:41, Fabrice Chapuis wrote:
> What is the xid type and how can I cast integer value to make
> pg_xact_commit_timestamp to work?
The xid type is... xid. You'll need to cast as a string instead of an integer:
xof=# select pg_xact_commit_timestamp('53013547'::xid);
> On May 4, 2023, at 18:00, Wen Yi wrote:
>
> Hi team,
> I am a newbie to the postgres.
> When I am studying the compiler,the text book tell me there is there type of
> compiler.
> • Assembly Language Format
> • Relocatable Binary Format
> • Memory-Image (Load-and-Go)
> On May 2, 2023, at 12:15, Tomas Pospisek wrote:
>
> Oh, I think your idea to use pgbouncer to take care of the SSL termination is
> elegant. I don't think me I'd characterize it as a hack if properly set up.
> Why do you consider it a hack?
It's really only a hack in the sense that
> On Apr 27, 2023, at 12:40, Michael Xu wrote:
> In our env, it throws 42P01:relation "ads.MyTableName" does not exist.
The function of double quotes in SQL is to allow you do include characters that
would otherwise not be legal in an identifier (as well as making the identifier
> On Apr 25, 2023, at 09:35, Peter Geoghegan wrote:
>
> It's skipped by VACUUM, but not by ANALYZE. So if you're using the
> reloption version of index_cleanup=off, it isn't necessarily going to
> stop autovacuum/autoanalyze from doing pending list cleanup.
Ugh, thanks. I wasn't aware that
Does VACUUM (INDEX_CLEANUP OFF) flush the pending list for GIN indexes, or is
that skipped as well?
> On Apr 18, 2023, at 03:45, Robert Sjöblom wrote:
> I'm aware of that. But you can, however, do something like:
>
> SELECT * FROM FOO WHERE CTID = (SELECT MAX(CTID) FROM FOO);
>
> on both sides. The idea being that if I change FOO, the CTID of the changed
> row will not be the same on both
> On Apr 18, 2023, at 01:20, Robert Sjöblom wrote:
> Another idea we've had would be to use CTID to fetch the last row
> (update/insert) in each table on both sides and compare row content, is this
> feasible? Is it safe to rely on CTIDs across logical replication?
No. CTIDs aren't sent
> On Mar 29, 2023, at 12:11, Sebastien Flaesch
> wrote:
> But to make PostgreSQL more Informix-compatible, zero should have been
> considered as well.
There is an infinite family of strange features that various databases have
(DUAL from Oracle, anyone?); PostgreSQL will rapidly become
> On Mar 28, 2023, at 03:39, Sebastien Flaesch
> wrote:
> Do I have to cast() ?
Yes:
select * from t where ctid='(0,1)'::tid;
The string representation can be up to 17 characters: 10 for the page number, 4
for the tuple number, and three for the delimiters.
Remember that updating
> We have an Oracle DB which is around 1TB and we want to migrate to
> PostgreSQL that have a new table structure, so we want to perform
> data transformation and real time CDC from Oracle to PostgreSQL. Do
> we have any good open source tool to achieve this with No Coding
> involved.??
To meet
> On Mar 6, 2023, at 16:24, Siddharth Jain wrote:
> My question: How can it then store a B Tree on disk? I would think storing a
> B Tree requires storing disk offset addresses and so on (for a node to
> navigate to another etc.). For this, one would need to write directly to the
> disk
> On Feb 21, 2023, at 10:48, Brad White wrote:
>
> Running the table_bloat_check query from here
> https://github.com/pgexperts/pgx_scripts/blob/master/bloat/table_bloat_check.sql
>
> shows some tables with over 20MB and over 20% bloat while my threshold is set
> to 0.1.
> On Feb 21, 2023, at 09:54, Brad White wrote:
> Any suggestions on how to proceed?
First, look at pg_stat_user_tables to see how many inserts etc. have occurred
on the tables that are not showing an autovacuum; they may have simply not
reached the threshold yet. If they have, do a VACUUM
> On Feb 20, 2023, at 17:54, Bryn Llewellyn wrote:
>
>
> I’ve no idea how I might have found this without human help.
That sounds like an excellent documentation patch!
> On Feb 20, 2023, at 11:57, Bryn Llewellyn wrote:
> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
> far) a second session will not see the effect of my SQL's. It sees this only
> when I send over "commit". (If I send over "rollback" instead of "commit",
>
> On Feb 18, 2023, at 18:52, Ian Lawrence Barwick wrote:
>
> Historical trivia: PostgreSQL had a (backend) "autocommit" GUC in 7.3
> only, which remained as
> a dummy GUC until 9.5 (see: https://pgpedia.info/a/autocommit.html ).
Well, that was a pretty whacky idea. :-)
1 - 100 of 268 matches
Mail list logo