> On 14 Feb 2024, at 21:56, Tom Lane wrote:
> Ayush Vatsa writes:
>> 2. While going through the contrib folder I find that in the regress test
>> there are two .out files with respect to a single .sql file, example
>> citext.out and citext_1.out wrt citext.sql. Why is it so? Even in git blame
>>
Hi,
quick question: What would be the cases for a query_id in pg_stat_activity not
showing up in pg_stat_statements.queryid assuming pg_stat_statements.max is not
yet reached?
Regards
Daniel
Hi,
On Thu, Feb 15, 2024 at 10:52:42AM +, Daniel Westermann (DWE) wrote:
>
> quick question: What would be the cases for a query_id in pg_stat_activity
> not showing up in pg_stat_statements.queryid assuming pg_stat_statements.max
> is not yet reached?
Well, first the query_id in pg_stat_acti
>
> So as I also tested the same as you posted, there has been no change in
> "ctid" , when I altered the column data type from 'int' to 'bigint' in the
> table, so that means full table rewriting won't happen in such a scenario.
No it was definitely rewritten - do not depend on the ctid to verif
On 2/15/24 08:16, Greg Sabino Mullane wrote:
So as I also tested the same as you posted, there has been no change
in "ctid" , when I altered the column data type from 'int' to
'bigint' in the table, so that means full table rewriting
won't happen in such a scenario.
No it was de
On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
wrote:
> That is a mixed bag:
>
Ha! Good point. Our contrived example table does suffer from that, so
perhaps the test should be:
create table int_test(c1 int, c2 int);
Cheers,
Greg
Hi. Our "app" depends on many ROLEs and SCHEMAs, and manages GRANTs between
those.
Typically, each "instance" of our app lives in its own DB, and uses a
naming convention for its ROLEs, to make those role names unique
per-app-instance. All the app roles are created by a single master role
(the "own
On 2/15/24 09:00, Greg Sabino Mullane wrote:
On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
That is a mixed bag:
Ha! Good point. Our contrived example table does suffer from that, so
perhaps the test should be:
create table int_test(c1 int, c2
Hi,
On 15.02.2024 20:07, Dominique Devienne wrote:
And now with V16.1 ===
ddevienne=> create role zowner nologin createrole; -- owner of app's
schemas and manager of related roles
CREATE ROLE
ddevienne=> set role zowner;
ERROR: permission denied to set role "zowne
On Thu, 15 Feb 2024 at 22:40, Adrian Klaver
wrote:
> On 2/15/24 09:00, Greg Sabino Mullane wrote:
> > On Thu, Feb 15, 2024 at 11:43 AM Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>> wrote:
> >
> > That is a mixed bag:
> >
> >
> > Ha! Good point. Our contrived example table does suffer f
On Thu, Feb 15, 2024 at 06:07:51PM +0100, Dominique Devienne wrote:
> When I read about v16, I thought great, this fits our intent, a single "owner"
> ROLE with CREATEROLE which is limited to administering only the ROLEs it
> created itself. I've always been bothered by the mega-power of CREATEROLE
On Thu, Feb 15, 2024 at 12:18 PM veem v wrote:
>
> So one learning for me, i.e. one of the downside of fixed length data type
> is, with fixed length data types any future changes to it , will be a full
> table rewrite. And thus this sort of change for big tables will be a
> nightmare.
>
>
Yes, u
I really worry you are overthinking this. The only real concern is going
from INT to BIGINT, jumping from 4 to 8 bytes or storage. That really
covers 99% of real world cases, and the canonical advice is to start with
BIGINT if you ever think your rows are going to be numbered in the
billions. Also,
On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> On Tuesday, February 13, 2024, veem v wrote:
>
> float data types rather than numeric. This will give better performance.
>
>
> Only use an inexact floating-point data type if you truly understand what you
> are getting yourself into
On 2024-02-14 11:25:48 +0100, Daniel Gustafsson wrote:
> > On 14 Feb 2024, at 10:59, Simon Connah
> > wrote:
>
> > This is probably a stupid question so I apologies in advance.
>
> There is no such thing.
>
> > What I think is the best way to do this is to do a pg_dump of the
> > database (usi
On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer wrote:
> On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > On Tuesday, February 13, 2024, veem v wrote:
> >
> > float data types rather than numeric. This will give better
> performance.
> >
> >
> > Only use an inexact floating-point
On 2024-02-14 10:02:37 -0500, Greg Sabino Mullane wrote:
> "Fiscal year" double precision,
>
> This column is an INTEGER in your other table, so your schema is not even
> internally consistent! Try to use TEXT, INT, DATE and TIMESTAMPTZ whenever
> possible,
While using double precision fo
On 2024-02-15 23:51, Peter J. Holzer wrote:
On 2024-02-14 11:25:48 +0100, Daniel Gustafsson wrote: On 14 Feb 2024,
at 10:59, Simon Connah wrote:
This is probably a stupid question so I apologies in advance.
There is no such thing.
What I think is the best way to do this is to do a pg_dump of
On 2024-02-15 16:51:56 -0700, David G. Johnston wrote:
> On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer wrote:
> On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > On Tuesday, February 13, 2024, veem v wrote:
> >
> > float data types rather than numeric. This will giv
On Fri, 16 Feb 2024 at 06:04, Peter J. Holzer wrote:
> On 2024-02-15 16:51:56 -0700, David G. Johnston wrote:
> > On Thu, Feb 15, 2024 at 4:31 PM Peter J. Holzer
> wrote:
> > On 2024-02-14 22:55:01 -0700, David G. Johnston wrote:
> > > On Tuesday, February 13, 2024, veem v wrote:
> >
Hello Friends,
We are newly moving to postgres database (yet to decide if it would be an
on premise one or AWS aurora postgres). However , we want to understand
what encryption / decryption techniques are available in the postgres
database.
We may have some sensitive/"personal information" (lik
21 matches
Mail list logo
