On 11/11/20 21:56, Simon Riggs wrote:
[ŝnip]
REINDEX VERIFY
After the new index is created, but before we drop the old index:
Check whether the two indexes match:
* checks whether the previous index had pointers to row versions that
don't exist
* checks whether the heap has rows that were not in
On 20/9/19 4:06, Michael Paquier wrote:
On Thu, Sep 19, 2019 at 05:40:41PM +0300, Alexey Kondratov wrote:
On 19.09.2019 16:21, Robert Haas wrote:
So, earlier in this thread, I suggested making this part of ALTER
TABLE, and several people seemed to like that idea. Did we have a
reason for droppi
On 19/12/19 4:03, Bruce Momjian wrote:
On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote:
On 11/25/19 15:05, Jeremy Schneider wrote:
... the cost of doing the individual index lookups across 180
partitions (and 180 indexes) was very high, so they stored max and min
txn id per par
On 31/12/19 14:35, Tom Lane wrote:
Peter Eisentraut writes:
With the attached patch, I propose to enable the colored output by
default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it
Hackers,
While working on an application, the need arose to be able
efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
others)
... so please find attached a trivial patch which adds the
functionality. The "uuid_version_bits()" function (from the test suite?)
seems
On 6/4/19 18:35, Tom Lane wrote:
Jose Luis Tallon writes:
While working on an application, the need arose to be able
efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
others)
... so please find attached a trivial patch which adds the
functionality.
No particular
On 8/4/19 17:06, Robert Haas wrote:
On Sun, Apr 7, 2019 at 10:15 AM David Fetter wrote:
I see some.
UUIDs turn out to be super useful in distributed systems to give good
guarantees of uniqueness without coordinating with a particular node.
Such systems have become a good bit more common since
On 7/6/23 23:37, Andres Freund wrote:
[snip]
I think we're starting to hit quite a few limits related to the process model,
particularly on bigger machines. The overhead of cross-process context
switches is inherently higher than switching between threads in the same
process - and my suspicion is
On 8/6/23 15:56, Robert Haas wrote:
Yeah, I've had similar thoughts. I'm not exactly sure what the
advantages of such a refactoring might be, but the current structure
feels pretty limiting. It works OK because we don't do anything in the
postmaster other than fork a new backend, but I'm not sure
On 18/6/20 19:41, Cary Huang wrote:
Hi all
Having read through the discussion, I have some comments and
suggestions that I would like to share.
I think it is still quite early to even talk about external key
management system even if it is running on the same host as PG. This
is most likely
On 10/4/20 15:49, Robert Haas wrote:
On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian wrote:
Good point, but if there are multiple APIs, it makes shell script
flexibility even more useful.
[snip]
One thing I do think would be realistic would be to invent a set of
tools that are perform certain lo
On 10/4/20 21:38, Andres Freund wrote:
Hi,
On 2020-04-10 12:20:01 -0400, Robert Haas wrote:
- We're only talking about writing a handful of tar files, and that's
in the context of a full-database backup, which is a much
heavier-weight operation than a query.
- There is not really any state that
On 30/4/20 6:22, Thomas Munro wrote:
On Thu, Apr 30, 2020 at 12:26 PM Tomas Vondra
wrote:
Yeah, I think the question is what are the expected benefits of using
raw devices. It might be an interesting exercise / experiment, but my
understanding is that most of the benefits can be achieved by usi
On 7/2/19 10:03, Dave Page wrote:
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
wrote:
I'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension)
Hmm... FWIW, just get it in core altogether? Seems small and useful
enough... if it carries the o
On 7/2/19 23:03, Andres Freund wrote:
Hi,
On 2019-02-07 09:03:06 +, Dave Page wrote:
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
wrote:
I suggest we declare it deprecated in PG12 and remove it altogether in PG13.
Much as I'd like to get rid of it, we don't have an alternative for
Win
We were just busy shooting down a different suggestion of
behavior-changing GUCs. A GUC that turns all ALTERs into no-ops
sure seems like a foot-gun to me.
Yeah, I like EXPLAIN better.
+1 for EXPLAIN
IMVHO, and for "symmetry" with existing mechanisms:
* EXPLAIN ALTER TABLE ==> "DDL dry ru
On 20/12/18 6:53, David Rowley wrote:
Back in 2016 [1] there was some discussion about using the POPCNT
instruction to improve the performance of counting the number of bits
set in a word. Improving this helps various cases, such as
bms_num_members and also things like counting the allvisible an
Hackers,
Musing some other date-related things I stumbled upon the thought
that naming the upcoming release PostgreSQL 20 might be preferrable to
the current/expected "PostgreSQL 13".
Cons:
* Discontinuity in versions. 12 -> 20. Now that we have the precedent
of 9.6 -> 10 (for very g
On 11/6/19 10:49, Peter Eisentraut wrote:
On 2019-04-09 08:04, Peter Eisentraut wrote:
On 2019-04-08 23:06, Andres Freund wrote:
The randomness based UUID generators don't really have dependencies, now
that we have a dependency on strong randomness. I kinda thing the
dependency argument actual
On 11/6/19 13:11, Peter Eisentraut wrote:
On 2019-06-11 12:31, Jose Luis Tallon wrote:
I wonder whether re-implementing some more of the extension's (ie. UUID
v5) in terms of PgCrypto and in-core makes sense / would actually be
accepted into core?
Those other versions are significantly
On 2/7/19 9:26, Peter Eisentraut wrote:
On 2019-06-30 14:50, Fabien COELHO wrote:
I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
it is available in core?
That would probably require an extension version update dance in
pgcrypto. I'm not sure if it's worth that. Thou
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
This seems most reasonable, and is what José Luis proposed upthread. We
don't have to bump the pgcrypto extension version
On 5/7/19 11:00, Peter Eisentraut wrote:
On 2019-07-05 00:08, Jose Luis Tallon wrote:
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
Updated patch with this change
On 13/7/19 8:31, Fabien COELHO wrote:
Hello Jose,
Hello, Fabien
Thanks for taking a look
Got it, and done. Please find attached a v2 patch with the upgrade
script included.
Patch v2 applies cleanly. Compiles cleanly (once running configure
--with-uuid=...). Local make check ok. Doc bui
On 12/4/25 18:59, Thomas Munro wrote:
It's hard to know how to set io_workers=3.
Hmmm enable the below behaviour if "io_workers=auto" (default) ?
Sometimes being able to set this kind of parameters manually helps
tremendously with specific workloads... :S
[snip]
Here's a patch to repla
25 matches
Mail list logo
