. 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,
Seems too easy but have you tried
psql -p 6432 -h localhost words_de
?
On Sun, Dec 1, 2024 at 3:59 PM Alexander Farber
wrote:
> My problem is related to
> https://github.com/docker-library/postgres/pull/440/files
>
> But I am yet not sure how to enable listening at localhost again
>
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
NFLICT DO UPDATE.
--
Peter Geoghegan
tually make any promises about not getting unique
violations. Only ON CONFLICT DO UPDATE (and ON CONFLICT DO NOTHING)
make such a promise. That's the main reason why Postgres supports
both.
--
Peter Geoghegan
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.
|_|_) |
ind by fillfactor in each case. In
general page splits tend to come in distinct "waves" after CREATE
INDEX is run.
--
Peter Geoghegan
On Wed, Oct 30, 2024 at 11:39 AM Don Seiler wrote:
> Thanks Peter, I'll look into that shortly.
It sounds like you have no updates and deletes. Right? So the only
thing that could be different is the way that the pages are being
split (aside from variations in the width of index tuple
sistently:
https://www.youtube.com/watch?v=p5RaATILoiE&t=2079s
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f21668f3
Of course, this is only a guess. I vaguely recall a complaint that
sounded vaguely like yours, also involving partitioning.
--
Peter Geoghegan
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
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.
1 - 100 of 966 matches
Mail list logo
