I cheat by using sed to remove "ONLY ON " from the CREATE statements.
On 1/27/23 15:30, Rumpi Gravenstein wrote:
Tom/Christophe I now understand. Thanks for the clear explanation.
On Fri, Jan 27, 2023 at 4:16 PM Tom Lane wrote:
Rumpi Gravenstein writes:
> We are using the
On 1/27/23 14:31, David G. Johnston wrote:
On Fri, Jan 27, 2023 at 2:25 PM Rob Sargent wrote:
On 1/27/23 14:20, David G. Johnston wrote:
On Fri, Jan 27, 2023 at 1:59 PM Rob Sargent
wrote:
I'm trying to craft SQL to invoke a sequence nextval once per
grouped
On Fri, Jan 27, 2023 at 2:25 PM Rob Sargent wrote:
> On 1/27/23 14:20, David G. Johnston wrote:
>
> On Fri, Jan 27, 2023 at 1:59 PM Rob Sargent wrote:
>
>> I'm trying to craft SQL to invoke a sequence nextval once per grouped
>> value.
>>
>>
> This seems like a very unusual usage of
Tom/Christophe I now understand. Thanks for the clear explanation.
On Fri, Jan 27, 2023 at 4:16 PM Tom Lane wrote:
> Rumpi Gravenstein writes:
> > We are using the pg_indexes view (indexdef) to retrieve the index
> > definition.
>
> Ah.
>
> > Are you saying that as a normal part of building
On 1/27/23 14:20, David G. Johnston wrote:
On Fri, Jan 27, 2023 at 1:59 PM Rob Sargent wrote:
I'm trying to craft SQL to invoke a sequence nextval once per
grouped value.
This seems like a very unusual usage of nextval/sequences...
with cleanup as (
select DISTINCT e.ma
On Fri, Jan 27, 2023 at 1:59 PM Rob Sargent wrote:
> I'm trying to craft SQL to invoke a sequence nextval once per grouped
> value.
>
>
This seems like a very unusual usage of nextval/sequences...
with cleanup as (
select DISTINCT e.ma, coalesce(e.pa, 'fix') as pa from ...
), compute as (
Rumpi Gravenstein writes:
> We are using the pg_indexes view (indexdef) to retrieve the index
> definition.
Ah.
> Are you saying that as a normal part of building an index, there are short
> periods of time where the pg_indexes view will show the index with ON ONLY
> specified?
No, there's no
> On Jan 27, 2023, at 13:01, Rumpi Gravenstein wrote:
>
> We are using the pg_indexes view (indexdef) to retrieve the index definition.
This is as expected. Once the index is created on the partitioned set of
tables, the index on the *root* table will be ON ONLY that table; the child
We are using the pg_indexes view (indexdef) to retrieve the index
definition.
Are you saying that as a normal part of building an index, there are short
periods of time where the pg_indexes view will show the index with ON ONLY
specified?
On Fri, Jan 27, 2023 at 3:53 PM Tom Lane wrote:
> Rumpi
I'm trying to craft SQL to invoke a sequence nextval once per grouped value.
So far I have this:
with husb as(
select e.ma, count(distinct coalesce(e.pa, nextval('egogen')::text))
as mates
from emp_all_by3 e group by e.ma order by mates
)
select mates, count(*)
from husb
Rumpi Gravenstein writes:
>> We have recently discovered that on some of our partitioned tables indexes
>> that were created as:
>>
>> CREATE UNIQUE INDEX chapter_u01 USING btree (dur_uk, catalog_id)
>>
>> somehow changed to include the ON ONLY option:
>>
>> CREATE UNIQUE INDEX chapter_u01 *ON
> CREATE UNIQUE INDEX chapter_u01 USING btree (dur_uk, catalog_id)
How did you do the above without the table name?
That's a cut/paste error. The original index create is:
create unique index chapter_u01 on chapter (dur_uk,catalog_id);
On Fri, Jan 27, 2023 at 3:34 PM Adrian Klaver
wrote:
>
On 1/27/23 12:23, Rumpi Gravenstein wrote:
We are on PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
8.5.0 20210514 (Red Hat 8.5.0-10), 64-bitPostgreSQL 14.5 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat
8.5.0-10), 64-bit
We have recently discovered that
Whoops ... fixed the subject line.
On Fri, Jan 27, 2023 at 3:23 PM Rumpi Gravenstein
wrote:
> We are on PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bitPostgreSQL 14.5 on
> x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red
We are on PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
8.5.0 20210514 (Red Hat 8.5.0-10), 64-bitPostgreSQL 14.5 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat
8.5.0-10), 64-bit
We have recently discovered that on some of our partitioned tables indexes
that
On 2023-01-27 19:12:08 +0700, Max Nikulin wrote:
> I am unsure what is the proper mailing list to discuss an the issue,
> this one or pgsql-doc.
>
> PostgreSQL has a reputation of software with excellent support of time
> zones, so some people take recommendation to use "timestamp with time zone"
> So forget about performance issues (there will ALWAYS be need for faster
> systems). The ease and functionality with UUID
> is so mutch better. Sequence keys are a terrible idea!
>
> // GH
>
Wow. I am not alone
>
Hello,
I'm with PostgreSQL for some years now, coding in ESQL/C, setting up
clusters inhouse and for our customers running our Library Management
System now on top of PostgreSQL (formerly Informix, Oracle and Sybase)
and migrated databases of these old DBSes to PostgreSQL.
Said that (and
Hi,
I am unsure what is the proper mailing list to discuss an the issue,
this one or pgsql-doc.
PostgreSQL has a reputation of software with excellent support of time
zones, so some people take recommendation to use "timestamp with time
zone" type excessively literally. I mean the "Don't do
Hello.
I have been using UUID for quite a long time now. The reason I began to use
UUID was the need to be able to move data between
databases and the need to create record outside the database. You should use
UUID as a primary key for a record and also have
some bookkeeping UUID:s in the
20 matches
Mail list logo
