On 2024-10-12 09:02:37 -0700, Adrian Klaver wrote:
> On 10/12/24 03:17, Peter J. Holzer wrote:
> > On 2024-10-11 21:21:16 -0700, Adrian Klaver wrote:
> > > On 10/11/24 20:10, admin@iseki.space wrote:
> > > > I found. Maybe we should reply to the mailing list only. O
possible. For me it's much better to get all the mails through
the list (so I can use the List-ID header to filter them into the
appropriate folder) and live with the extra copies in my inbox. I would
prefer to not get those extra copies, but there is nothing the list can
do about them, that'
I'm using Thunderbird. If you have better software, tell me please.
I'm using (neo)mutt, but these days the limitations of a text-only
mailer can be quite noticeable.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |
On 2024-10-05 15:40:06 -0700, Adrian Klaver wrote:
> On 10/5/24 15:25, Peter J. Holzer wrote:
> > On 2024-10-05 17:03:08 -0400, Tom Lane wrote:
> > > "Peter J. Holzer" writes:
> > > > Again, I'm not arguing for such a change, but I'm wondering if
On 2024-10-05 17:03:08 -0400, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > Again, I'm not arguing for such a change, but I'm wondering if recording
> > transaction_timestamp just after the snapshot might be a safe change or
> > whether that might b
On 2024-10-05 09:59:00 -0700, Adrian Klaver wrote:
> On 10/5/24 02:14, Peter J. Holzer wrote:
> > On 2024-09-25 18:09:44 -0400, Tom Lane wrote:
> > > "Peter J. Holzer" writes:
> > > Admittedly, that would normally not be a very long interval if BEGIN
> >
On 2024-09-27 18:37:35 -0400, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > As you can see, adding the primary key takes just as much time as
> > creating the unique index. So it doesn't look like PostgreSQL is able to
> > take advantage of the existing ind
On 2024-09-25 18:09:44 -0400, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > On 2024-09-25 13:53:30 -0700, Christophe Pettus wrote:
> >> This might well be a failure of imagination on my part, but when would
> >> it pragmatically matter that the snapshot is
Hello Folks,
Thanks for Your inspiration; and I made some progress (found
a way to avoid the issue).
The issue is most likely not related to postgres.
Ron Johnson said:
>> A configuration problem on the machine(s) can be ruled out,
> Famous last words.
Trust me. :)
> Is there a way to test
My application is trying to connect the database server, and meanwhile
tries to talk to the KDC server for a service ticket.
Earlier these TCP connections did run like this, and were successful:
13:57:53.788797 IP6 clientIPv6.54143 > serverIPv6.88: Flags [S], seq
4189109662, win 65535, options [
me: 5051.584 ms (00:05.052)
hjp=> alter table t add primary key(i);
ALTER TABLE
Time: 5222.788 ms (00:05.223)
As you can see, adding the primary key takes just as much time as
creating the unique index. So it doesn't look like PostgreSQL is able to
take advantage of the existing index (w
ally
triggers the snapshot.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
cording to the rules of their language and C collation is in most
cases very different.
hp
[1] I actually have LC_COLLATE=POSIX set in the shell. But I'm not
normal.
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h.
y usual distributions. It's now in both Debian and Ubuntu,
so that will change.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
On 2024-09-21 20:55:13 +0530, Lok P wrote:
> On Sat, Sep 21, 2024 at 8:07 PM Peter J. Holzer wrote:
[... lots of code elided. method2 used 1 insert per row, method3 1
insert for 50 rows ...]
> On my laptop, method2 is about twice as fast as method3. But if I
> connect to a da
bout twice as fast as method3. But if I
connect to a database on the other side of the city, method2 is now more
than 16 times faster than method3 . Simply because the delay in
communication is now large compared to the time it takes to insert those
rows.
hp
--
_ | Peter J. Holzer
On 2024-09-21 15:06:45 +0530, veem v wrote:
> On Sat, 21 Sept 2024 at 03:47, Peter J. Holzer wrote:
>
> On 2024-09-20 14:11:38 -0700, Adrian Klaver wrote:
> > On 9/20/24 1:01 PM, veem v wrote:
> > > Able to reproduce this deadlock graph as below. Now my
>
from the target table that attempt to match data_source`
rows" for me sort of sounds like those columns have to have a counterpart
in the data_source, which k1 hasn't. Also maybe the order is the wrong
way around? "Match rows in the target to rows in the data_source" wo
On 2024-09-19 20:12:13 +0200, Paul Foerster wrote:
> Hi Peter,
> > On 19 Sep 2024, at 19:43, Peter J. Holzer wrote:
> >
> > I wrote a small script[1] which prints all unicode code points and a few
> > selected[2] longer strings in order. If you run that before and af
ccur. So an application designed for serializable
would have some kind of retry logic already in place.
SO that leads as to another solution:
Retry each batch (possibly after reducing the batch size) until it
succeeds.
hp
--
_ | Peter J. Holzer| Story must make more sense
ndexes on text (etc.) columns
just to be sure.
hp
[1] https://git.hjp.at:3000/hjp/pgcollate
[2] The selection is highly subjective and totally unscientific.
Additions are welcome.
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
On 2024-09-14 20:26:32 +0530, yudhi s wrote:
>
>
> On Sat, Sep 14, 2024 at 4:55 PM Peter J. Holzer wrote:
>
>
> Which in turn means that you want as little overhead as possible per
> batch which means finding those 5000 rows should be quick. Which brings
&g
On 2024-09-14 21:21:45 +0530, yudhi s wrote:
> On Sat, Sep 14, 2024 at 4:17 PM Peter J. Holzer wrote:
> On 2024-09-14 00:54:49 +0530, yudhi s wrote:
> > As "thiemo" mentioned , it can be done as below method, but if
> > we have multiple lookup tables
ave any method exists
> in
> postgres (say like forall statement in Oracle) which will do the batch dml.
> Can
> you please guide me here, how we can do it in postgres.
Postgres offers several server side languages. As an Oracle admin you
will probably find
as ( select substB from cfgB where keyB = :param4 )
insert into target(val1, val2, val3, val4)
select :param1, cA.substA, :param3, cB.substB
from cA, cB
However, I agree with Rob here. It's probably better to do the
substitution in Java.
hp
--
_ | Peter J. Holzer
now and would
probably lean more to your option 1 (let the application add columns to
an "extension table").
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
T was more than twice as fast as 8 parallel COPY
operations (and about 8 times as fast as a single COPY).
Details will have changed since then (I should rerun that benchmark on
a current system), but I'd be surprised if COPY became that much faster
relative to INSERT ... SELECT.
hp
--
_ |
Please remove p...@mipta.com from the distribution list
thank you
Peter L Martin
MIPTA
ABN 74 843 345 087
p...@mipta.com <mailto:p...@mipta.com>
Mobile Au: +61 (0)437 414 689
Todays problems will not be solved, if we think the same, as when we created
them! - Albert Ei
Please remove p...@mipta.com from the List
Thank you
Peter L Martin
MIPTA
ABN 74 843 345 087
p...@mipta.com <mailto:p...@mipta.com>
Mobile Au: +61 (0)437 414 689
Todays problems will not be solved, if we think the same, as when we created
them! - Albert Einstein
Information i
On Mon, Sep 2, 2024 at 4:58 PM Peter Geoghegan wrote:
> On Mon, Sep 2, 2024 at 4:35 PM Pavel Luzanov wrote:
> > If it helps, without creating index on id column, the numbers will be
> > much closer:
>
> Yes, avoiding all index vacuuming seems useful. It makes the test cas
're writing extra FPIs to set hint
bits. But that explanation only works if you assume that page-level
checksums are in use (or that wal_log_hints is turned on).
--
Peter Geoghegan
ally cause an increase in the number of WAL records written?
I'd have thought that that was simply impossible.
--
Peter Geoghegan
inated in
pages that only contained existing LP_UNUSED items when scanned by
VACUUM?
--
Peter Geoghegan
ed to WAL, buffers, and
CPU time that changed.
Perhaps I'm not thinking of something obvious. Maybe it's extra
VISIBILITY records? But I'd expect the number of VISIBILITY records to
match the number of pages frozen, given these particulars. VACUUM
VERBOSE at least shows that that hasn't changed.
--
Peter Geoghegan
s
> and the total size of the WAL. Instead, WAL numbers have significantly
> degraded.
>
> What am I doing wrong?
That does seem weird.
CC'ing the authors of the relevant VACUUM enhancements.
--
Peter Geoghegan
On 2024-08-31 10:35:01 -0700, Adrian Klaver wrote:
> On 8/31/24 09:54, Peter J. Holzer wrote:
> > 'Tis the season again.
> >
> > Ubuntu 24.04.1 has just been released, so many Ubuntu LTS users will now
> > be prompted to upgrade from 22.04 to 24.04.
>
> Wh
make sure you have a backup before the
upgrade.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
On 2024-08-23 08:13:40 +0200, Peter J. Holzer wrote:
> On 2024-08-22 16:09:47 +0500, Muhammad Usman Khan wrote:
> > For validation of databases, you can use the following approach
> >
> > /usr/pgsql-16/bin/pg_dump -d postgres -h localhost -p 5428 | md5sum >
> &g
backup of a database to a
> NEW server.
>
> Is there a way to ensure the data integrity is in tact, and user ID and
> access works liked how it was in the old server?
And of course your method doesn't check at all whether "user ID and
access works liked how i
need to be postgres or root to do this. Be careful!
Watching the access times may be useful, too, but on Linux by default
the access time is only updated under some special circumstances, so
this may be misleading.
hp
--
_ | Peter J. Holzer| S
Program Files\PostgreSQL\15\data"
> --locale
> "Turkish,Türkiye" -W
> XXX debug raw: getopt optarg = "Turkish,Türkiye"
> XXX debug hex: getopt optarg = { 54 75 72 6b 69 73 68 2c 54 fc 72 6b 69
> 79
> 65 }
> XXX debug txt: getopt
On 2024-07-16 02:00:27 +0530, sud wrote:
>
> On Mon, Jul 15, 2024 at 7:58 PM Peter J. Holzer wrote:
> > Hm, true.
> >
> > You can always do
> >
> > UPDATE tab SET id = id;
> >
> > followed by
> >
>
rel_group_user".
> ERROR: deleting FISPTAPPGS401DA/TAPd.public.access_user
> [snip]
Is it possible that some other process created an entry in
rel_group_user between these two queries?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_
On 2024-07-15 13:53:25 +0200, Laurenz Albe wrote:
> On Sun, 2024-07-14 at 00:05 +0200, Peter J. Holzer wrote:
> > On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> > > Dropping a column is fast, but doesn't reclaim the space.
> > > VACUUM won't block
the (former) content of dropped columns, maybe
CLUSTER does, too?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
On 2024-07-10 07:27:29 -0700, Ian Harding wrote:
>
>
> On Wed, Jul 10, 2024 at 7:10 AM Peter J. Holzer wrote:
>
> On 2024-07-09 03:35:33 +, Buoro, John wrote:
> > I've dusted off my C books and coded a solution.
> [...]
> > When using SSP
significant amount of data which is only needed for
constructing further queries but doesn't enter the final report. In this
case keeping it in the database might be quite a bit faster than
transferring it back and forth between the database and the client.
OTOH, temporary tables or CTEs might be
ow the complete user/group administration to be outsourced
to AD. Only GRANTs to database objects like tables, views or functions
would need to be done at each database.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
On 2024-07-06 11:09:23 +0530, Krishnakant Mane wrote:
>
> On 7/5/24 21:10, Peter J. Holzer wrote:
> > If I understand https://github.com/sraoss/pg_ivm correctly, the
> > materialized view will be updated within the same transaction. So it's
> > just the same as any
commit soon enough.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
the intended
contents.
Try it with
select array[email] from people;
If that looks promising, you can use it in an alter table statement
(Torsten already posted the solution, but I wanted to expand a bit on
how to find it).
hp
--
_ | Peter J. Holzer| Story must make more se
ting definition of "OPEN".
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
ave a
value to insert into the foreign key field(s).
There is no need to enter all companies before all locations. Indeed,
currval() can only (as the name implies) return the *current* value of a
sequence, so you can only use it to refer to the last entry you created.
If you create two companie
On 2024-05-23 17:23:14 -0400, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > One of our users reports getting the error message
> > "expected authentication request from server, but received H"
> > when trying to connect to the database.
>
> That
On Mon, May 27, 2024 at 01:51:56PM +0200, Laurenz Albe wrote:
! > ! Apart from hardware problems, one frequent cause is upgrading glibc
! > ! (if the index on a string column or expression).
! >
! > No, this is FreeBSD, we don't normally do such things... ;)
!
! You don't update the C library, o
On Mon, May 27, 2024 at 11:25:47AM +0200, Laurenz Albe wrote:
! On Sat, 2024-05-25 at 12:51 +0200, Peter wrote:
! > I just found Autovacuum run for 6 hours on a 8 GB table, VACUUM query
! > doesnt cancel, cluster doesn't stop, autovacuum worker is not
! > killable, truss shows no a
Good morning,
I just found Autovacuum run for 6 hours on a 8 GB table, VACUUM query
doesnt cancel, cluster doesn't stop, autovacuum worker is not
killable, truss shows no activity, after kill -6 this backtrace:
* thread #1, name = 'postgres', stop reason = signal SIGABRT
* frame #0: 0x
yte1('H') could mark a Copy Out response or a Flush command. Both don't
make sense in that context.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, &q
On 03.05.24 12:57, Muhammad Ikram wrote:
Tables which have an identity column in Oracle when migrated to
PostgreSQL, the data type of Identity column is changed to bigint from
number by the tools. This causes the size of column to be reduced to max
value supported by bigint which is way lower t
On 11.04.24 01:02, Tom Lane wrote:
And if not, why can't I write a stored procedure
or function that returns multiple result sets?
[ shrug... ] Lack of round tuits, perhaps. We don't have any
mechanism today whereby a stored procedure could say "please ship
this resultset off to the client, bu
of the solution. So you
ask how to achieve Y. However, Z would be better than Y for solving
X, but nobody can tell you because they don't know about X.
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at
On 2024-03-24 11:23:22 -0700, David G. Johnston wrote:
> On Sun, Mar 24, 2024 at 11:14 AM Peter J. Holzer wrote:
> It doesn't. Your statement
>
> > CREATE TABLE test1
> > (
> > c1 numeric NULL ,
> > c2 varchar(36) NOT NULL ,
>
not without searching the
table, so that is done first. Only then you have to check the index for
a possible duplicate value, so that's done later.
But as a user I actually prefer it that way. The more precisely the
database can tell me why the insert failed, the better.
hp
--
"jobs_pkey" PRIMARY KEY, btree (id)
"jobs_queue_id_id_idx" btree (queue_id, id)
"jobs_queue_id_idx" btree (queue_id)
Foreign-key constraints:
"jobs_queue_id_fkey" FOREIGN KEY (queue_id) REFERENCES queues(id)
If you do have very few very long queues it might be faster to query
each queue separately.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
u have so many connections. If you
have way more connections than you can reasonably expect, something is
wrong, And it is better to fix the root cause than to just hit
everything over the head with a hammer periodically.
hp
--
_ | Peter J. Holzer| Story must make more sense than
scan which may take a long
time.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
s are
[...]
> the type information (typmod if there is one and the OID of the
> composite type),
Is it necessary to store this in every row? Can a column contain
different composite types?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) |
hich just terminates all database
connections - a bit drastic but effective) if free space runs low:
https://github.com/hjp/platzangst
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles St
On 28.02.24 16:09, Dominique Devienne wrote:
We use generated columns extensively.
And we have foreign-keys attached to those generated columns.
The fact they are always Stored thus wastes space in our case.
Any chance PostgreSQL might gain actual virtual / non-stored generated
columns soon? Eve
ave cached an
obsolete index.
Use "apt update" to update the index.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
On 19.02.24 04:32, Darryl Green wrote:
I note that in Postgresql 16 identity column handling in partitioned
tables has been aligned to the view that the partitioned table as a
whole is a single relation (and so a unique identity across partitions).
This makes sense.
The change that I think yo
On 2024-02-16 01:34:01 +0100, Peter J. Holzer wrote:
> On 2024-02-15 16:51:56 -0700, David G. Johnston wrote:
> > What you see with an exact type is what you get, which allows for
> > implementing
> > equality, unlike inexact which requires epsilon checking.
>
> You
On 2024-02-16 12:10:20 +0530, veem v wrote:
>
> 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:
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
le using double precision for fiscal year is rather grotesque
overkill (smallint would be sufficient) it isn't wrong: Any value you
could conceivably want to store for a fiscal year fits nicely (with lots
of room to spare) into a double precision.
I agree that consistency would be nice, though.
e schema, I run the
migration on the test database, then dump and commit it.
This project is small enough (86 tests in 10 files) that all test cases
can use the same test data. However, I could easily use different test
data for different tests.
hp
--
_ | Peter J. Holzer| Story m
ving himself wrong,
of course, but computing correctly is hard - and choosing a data type
which more closely mimics the way we learn to compute in primary school
doesn't necessarily make it easier. Mostly it just makes it harder to
spot the errors ;-).
hp
--
_ | Peter J. Ho
x would be
useful but doesn't exist, PostgreSQL usually just chooses the best of
the single column indexes and ignores the rest.
That said, my rule of thumb is to create just single column indexes at
first and only create composite indexes if they are necessary.
hp
--
_ | Pe
On 2024-02-13 01:53:25 +0530, veem v wrote:
> On Mon, 12 Feb 2024 at 03:40, Peter J. Holzer wrote:
>
> The fixed width types are those that the CPU can directly process:
> Integers with 16, 32 and 64 bits, floating point numbers with 32 and 64
> bits. The CPU can read
of first column. So , is it
> advisable here to go for similar approach of breaking the table into two ,
> if the total number of column reaches certain number/threshold for a
> table?
>
>
> I'm not sure of what Peter was testing exactly to get those 4-5x figures,
Sorry, I
is enough free space in the same
page and you can do a HOT update, but that's quite independent on
whether the row changes size.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, &qu
On 2024-02-11 22:23:58 +0530, veem v wrote:
> On Sun, 11 Feb 2024 at 19:02, Peter J. Holzer wrote:
>
> > Similarly for Number/Numeric data type.
>
> Number in Oracle and numeric in PostgreSQL are variable length types.
> But in PostgreSQL you also have a lot of
On 2024-02-11 13:25:10 +0530, veem v wrote:
> On Sun, 11 Feb 2024 at 05:55, Peter J. Holzer wrote:
> Yes. Numbers in Oracle are variable length, so most Oracle tables
> wouldn't contain many fixed length columns. In PostgreSQL must numeric
> types are fixed lengt
haracter) suggests that
accessing column 100 takes about 4 or 5 times as long as column 1, and
the access times for the coiumns between are pretty linear.
So there's a bit of a tradeoff between minimizing alignment overhead and
arranging columns for fastest access.
hp
--
use a chunk size which just
fits inside work_mem is faster. Of course finding that sweet spot takes
experimentation, hence time, and it may make little sense to experiment
for 20 hours just to save 40 minutes.
hp
--
_ | Peter J. Holzer| Story must make more sense than real
tructure large enough to hold a count for each individual id. But at
least then you'll have a much smaller table to use for further cleanup.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |
On 2023-12-24 14:27:19 -0800, Adrian Klaver wrote:
> On 12/24/23 13:43, Peter J. Holzer wrote:
> > I think you misunderstood Wilma. What she is asking for is a "keyword"
> > or "magic variable" (or whatever you want to call it) which you can
> > specify in
ration scripts but of course that assumes that you have
such scripts. If you are doing your deployments manually (especially by
cloning a template as described by Wilma) I can see how that feature
would make things easier and/or reduce the risk of errors.
hp
--
_ | Peter J. Holzer
uild completes successfully when the .a file is
> > smaller* (around 100 MB).
>
> Pure luck I suspect.
I seem to remember a 256MB limit for position independent code on x86.
The current man-page for GCC doesn't mention such a limit, though, so I
may be mistaken.
hp
--
_
ens, one can connect to the DB from a shell (that
> cluster has a single DB) w/o issues, and run queries just fine
If you do that, do you see the "hanging" queries in pg_stat_activity? If
so, what are they waiting for?
hp
--
_ | Peter J. Holzer| Story must mak
e calls to random())
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
ot be
very indicative of real performance.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
may not be
fast enough.
Another measure of "efficiency" might be how easy it is to use. Here,
bytea fields are very nice: They act just like varchar fields, no
special functions necessary.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) |
t just IP addresses.
So now that you have IP addresses again, are there any for which a
reverse lookup doesn't work?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
ng. If the database writes 1.5 GB/s of WALs and max_wal_size is
the default of 1GB, shouldn't there be a checkpoint about every 0.7
seconds instead of just every 22 seconds?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |
On 2023-11-25 10:49:56 -0500, Ron Johnson wrote:
> On Sat, Nov 25, 2023 at 4:49 AM Peter J. Holzer wrote:
> On 2023-11-24 13:06:45 -0500, Ron Johnson wrote:
> > On Fri, Nov 24, 2023 at 1:01 PM Peter J. Holzer
> wrote:
> > On 2023-11-20 22:03:06 -05
On 2023-11-24 13:06:45 -0500, Ron Johnson wrote:
> On Fri, Nov 24, 2023 at 1:01 PM Peter J. Holzer wrote:
> On 2023-11-20 22:03:06 -0500, Ron Johnson wrote:
> > Or row level security.
>
> Does that help here? AIUI row level security can be used to limit access
>
be accessed in a single
query.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
a in-house IT, who are not DBA's and have
> no access to data.
This doesn't answer the question why ALTER TABLE privilege would be
required.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |
y ALTER TABLE
> to perform any troubleshooting in the database.
This seems strange to me. What kind of troubleshooting requires to
ability to ALTER TABLE but not to do DML?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) |
1 - 100 of 941 matches
Mail list logo
