I’ve just found the list maintainers address, perhaps that goes somewhere.
slony1-general-ow...@lists.slony.info
On Wed, 19 Jan 2022 at 18:50, Tim Kane wrote:
> Apologies for posting here, but.. I have attempted to sign up to the Slony
> mailing lists and have been waiting over a week
Apologies for posting here, but.. I have attempted to sign up to the Slony
mailing lists and have been waiting over a week to be approved.
I’m suspicious that the mailing list functionality there is broken,
perhaps? Or the moderator is MIA.
When attempting to sign up, the following is displayed:
Thank you Tom, I appreciate the thorough explanation.
Good to confirm that it’s of no consequence.
Tim
On Fri, 22 May 2020 at 15:44, Tom Lane wrote:
> Tim Kane writes:
> > I've noticed a discrepancy in the return type for the gbt_cash_union
> > function...
> > On f
I've noticed a discrepancy in the return type for the gbt_cash_union
function...
On fresh instances of postgres 9.6.11, where the btree_gist extension is
newly created (version 1.2) yields a gbt_cash_union function with a return
type of gbtreekey16
While instances that have been upgraded from 9.6
That looks very useful indeed. Thanks Tomas
On Wed, Feb 12, 2020 at 8:32 PM Tomas Vondra
wrote:
> On Wed, Feb 12, 2020 at 10:23:22AM -0700, Michael Lewis wrote:
> >It may also be worth noting that it is possible to make autovacuum/analyze
> >more aggressive, perhaps only on the tables that see l
Every now and again, I will encounter an unexplained long-running query.
It’s a head scratcher moment, because this query that is still running for
20 minutes (not blocking) can be run independently in about 500ms
I can only assume that the problem query ran against the table(s) at a time
when it
On Wed, 17 Apr 2019 at 15:23, Adrian Klaver
wrote:
>
>
> The table definition and the size of the data set would help with
> interpreting the below.
The below example shows the issue on a table with just a single field. I
can demonstrate the problem wether there are 100 records or a million
r
On Tue, 16 Apr 2019 at 18:04, Adrian Klaver
wrote:
>
>
> Where are you seeing the rewrite in your case?
I’m unfamiliar with ctid (which I now plan to read up on)… I’ve been
looking at *relfilenode*
I’ve observed that relfilenode changes when altering from *old_type *
*à varchar(9) *and the op
Thanks everyone..
It seems that the first step:
old_type --> varchar(9)
still requires a table rewrite, while the reverse direction does not.
I'm curious about the performance implication of domain types, i expect
that cost is only at insert/update time? I guess we've been wearing that
cost up
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
This isn't ideal, let's just say.. legacy.
I wish to modify this type.. ideally to a text type with a length
constraint.. or even just
10 matches
Mail list logo
