order which can change, I guess?
Anyway, I don't have a pressing need for this, as I said I was just
curious.
hjp
[1] Mostly in MySQL I think, since it didn't have recursive queries of
any kind.
--
_ | Peter J. Holzer| Story must make mo
On 2025-04-20 08:28:22 -0700, Adrian Klaver wrote:
> On 4/20/25 02:10, Peter J. Holzer wrote:
> > I've just read Laurenz' blog post about the differences between Oracle
> > and PostgreSQL[1].
> >
> > One of the differences is that something like
>
you want to do updates in a
predictable order. For example to prevent deadlocks.
hjp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | h
especially for large tables.
So, is there a better way?
hjp
[1]
https://www.cybertec-postgresql.com/en/comparison-of-the-transaction-systems-of-oracle-and-postgresql/
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hj
t happens automatically with the
default settings.
> Even I enable it now, I can't figure out that error.
Just search the logs for the string "ERROR".
> By any chance, if I get that statement, what should I do?
1) Read the error message.
2) Figure out what caused the error
On 2025-02-07 09:22:13 +0100, Michał Kłeczek wrote:
>
>
> On 6 Feb 2025, at 22:03, Peter J. Holzer wrote:
>
> On 2025-02-04 22:41:38 +0100, Thiemo Kellner wrote:
>
>
> I might see what you want to point out. E.g. the table is COLOURS. The
>
magically change color just because you changed some text in the
database. So that change simply doesn't make sense and shouldn't be done
as part of a maintenance release. Confusing a few people who just happen
to open the dropdown in the wrong second is the least of your problems.
om what I
> can tell from @Laurenz's response above we have the names of the logs
> customised to posgtres-%d-%m-%y.
Earlier you wrote that the pattern was actually
«postgresql-%Y-%m-%d.log». «find ... -name "*.log"» would find that but
of course not «posgtres-%d-%m-%y».
ng similar working?
Yes. Cleaning up stuff is probably one of the most frequent uses of
cron.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writ
. It's not
really "number of seconds since 1970-01-01", but "number of days since
1970-01-01 times 86400 plus number of seconds in the current day".
So you can't use epoch to detect leap seconds.
And I don't think PostgreSQL keeps track of leap seconds int
one = false
ORDER BY id
FOR NO KEY UPDATE
2) Check whether the id you got first is the smallest of all.
3) If it isn't, rollback and start over.
4) If it is, you have now locked all the rows with the same lock_id and
can continue.
The advisory lock isn't needed then.
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
; | uniq -c | sort -n
to find the processes with the most open files (but be aware that lsof
reports file descriptors for each thread, so any multi-threaded programs
will be vastly inflated)
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
That might
work, but it probably also shouldn't do it by default.
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 2025-01-12 17:59:20 -0500, Tom Lane wrote:
> "Peter J. Holzer" writes:
> > The web framework Django will automatically and transparently rehash any
> > password with the currently preferred algorithm if it isn't stored that
> > way already.
>
> Re
ure should only be enabled by a GUC.
Additional question: Do current clients (especially the ODBC client)
even support AuthenticationCleartextPassword by default?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at
7;t really a faster way to do what Veem wants. There may
however be less disruptive way: He could create a new column with the
new values (which takes at least as long but can be done in the
background) and then switch it over and drop the old column.
hp
--
_ | Peter J. Holzer
new version
2) Drop the new (empty) database
3) Invoke pg_upgradecluster (see man-page for details)
4) Check that everything is ok
5) Drop old database and uninstall old version.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) |
On 2024-12-16 10:37:59 -0500, Ron Johnson wrote:
> On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer wrote:
>
> On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> > Local (socket-based) connections are typically peer-authenticated
> > (meaning that authenticatio
t; account, you should still be able to locally connect to PG.
True. But the client may not be on the same machine.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Cr
strong passwords, use a second factor. Or maybe
replace passwords with some other method (public keys, FIDO, ...)
altogether (in fact, I'd do that for system accounts).
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |
illion attempts (so the limit doesn't help either).
OTOH, the limit gives an attacker a very simple way to deny the service to
the legitimate used: Just enter a bogus password three times and boom -
account locked. (That threat can be mitigated by applying the limit per
IP address - but the a
restore a 25 GB database, so
that's what I'd try first. It's simple and you can easily test it
without disruption.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross,
7;t exist. You
should create that before restoring the backup. Or could fix the errors
after the fact but for that you need to understand what went wrong.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at
like this issue, or the parent one that everyone is linking to this.
That seems to be just about the way it is reported, not the behaviour.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Char
porary files, depending on your
work_mem settings), but I wouldn't expect them to happen just before the
configured limit is reached. So I'd double check the logs if there are
any errors.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) |
t yourself (which you
probably have to anyway because for me "so large it has to be streamed"
implies "at least possibly larger than 1 GB").
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at
7;t get mysql to work like postgresql, and any tips to speed up this
query on postgresql (which is all you can expect on a postgresql mailing
list) probably won't work on mysql.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
|
wn
processes since a *very* long time ago. Possibly even before Ubuntu even
existed. So I'm somewhat sceptical about that. Some other Unixes were
more permissive. I don't know what camp MacOS falls into.
hp
--
_ | Peter J. Holzer| Story must make more sense than realit
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
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
--
_ |
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
sufficient for that.
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
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
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
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
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 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
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
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
t_postgresql_column_bench where v{i} = 'a'"
t0 = time.clock_gettime(time.CLOCK_MONOTONIC)
csr.execute(q)
r = csr.fetchall()
print(r)
t1 = time.clock_gettime(time.CLOCK_MONOTONIC)
print(i, t1 - t0)
db.commit()
---
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
--
_
1 - 100 of 630 matches
Mail list logo
