Re: Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Michael Lewis
My apologies. You are correct. My brain may have already switched to holiday mode. Hopefully others will chime in shortly.

Re: How to REMOVE a fillfactor set by accident?

2020-12-31 Thread David G. Johnston
On Thu, Dec 31, 2020 at 1:24 PM Ron wrote: > Is there some way to REMOVE the fillfactor where it is set, so that > Postgres applies it's defaults? Would be great to have an output of > NULL everywhere where fillfactor is output instead of sometimes e.g. > 100 and more often NULL. > > I've already

Re: How to REMOVE a fillfactor set by accident?

2020-12-31 Thread Thomas Kellerer
Thorsten Schöning schrieb am 31.12.2020 um 21:13: Is there some way to REMOVE the fillfactor where it is set, so that Postgres applies it's defaults? Would be great to have an output of NULL everywhere where fillfactor is output instead of sometimes e.g. 100 and more often NULL. I've already tri

Re: How to REMOVE a fillfactor set by accident?

2020-12-31 Thread Ron
On 12/31/20 2:13 PM, Thorsten Schöning wrote: Hi all, I'm using the GUI tool pgModeler to maintain schemas and at some point in the past it used fillfactor 10 for some indexes by default. That seems to have changed in the meantime and most of my indexes don't have ANY fillfactor set explicitly.

How to REMOVE a fillfactor set by accident?

2020-12-31 Thread Thorsten Schöning
Hi all, I'm using the GUI tool pgModeler to maintain schemas and at some point in the past it used fillfactor 10 for some indexes by default. That seems to have changed in the meantime and most of my indexes don't have ANY fillfactor set explicitly. Is there some way to REMOVE the fillfactor wher

Re: Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Thorsten Schöning
Guten Tag Michael Lewis, am Donnerstag, 31. Dezember 2020 um 19:28 schrieben Sie: > select >t.reloptions > from pg_class t > join pg_namespace n on n.oid = t.relnamespace > where t.relname = 'clt_rec' > and n.nspname = 'public'; That outputs NULL, as well for other tested indexes. Add

Re: Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Michael Lewis
On Thu, Dec 31, 2020 at 11:18 AM Thorsten Schöning wrote: > Guten Tag Michael Lewis, > am Donnerstag, 31. Dezember 2020 um 18:20 schrieben Sie: > > > Why is your fillfactor so low?[...] > > I've just copied what my GUI-tool pgModeler generated as SQL right > now, that fill factor might have never

Re: Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Thorsten Schöning
Guten Tag Michael Lewis, am Donnerstag, 31. Dezember 2020 um 18:20 schrieben Sie: > Why is your fillfactor so low?[...] I've just copied what my GUI-tool pgModeler generated as SQL right now, that fill factor might have never been applied at all. > Perhaps a silly question, but do you have an in

Re: Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Michael Lewis
Why is your fillfactor so low? That seems pretty crazy, especially for a table with only 4 columns that are fixed width. 100 million rows with so little data in each row is not very much at all. You should be looking to other solutions before partitioning I expect. Perhaps a silly question, but do

Declarative partitioning and automatically generated row-IDs using BIGSERIAL

2020-12-31 Thread Thorsten Schöning
Hi all, I have the following table containing 100+ millions rows currently and which needs to be queried by "captured_at" a lot. That table stores rows for the last 6 years, but most of the queries focus on the last 15 months, 15 days or really only 15 minutes. > CREATE TABLE public.clt_rec( >

Re: plpgsql unit testing and code coverage

2020-12-31 Thread Pavel Stehule
čt 31. 12. 2020 v 13:21 odesílatel Joao Miguel Ferreira < joao.miguel.c.ferre...@gmail.com> napsal: > Hello, > > I'm a fan of unit testing and related matters but have used it only on > client applications, not on database implemented logic. I recently joined a > project whit dozens of PL function

Re: plpgsql unit testing and code coverage

2020-12-31 Thread Philip Semanchuk
> On Dec 31, 2020, at 7:20 AM, Joao Miguel Ferreira > wrote: > > Hello, > > I'm a fan of unit testing and related matters but have used it only on client > applications, not on database implemented logic. I recently joined a project > whit dozens of PL functions and procedures. > > So, it

plpgsql unit testing and code coverage

2020-12-31 Thread Joao Miguel Ferreira
Hello, I'm a fan of unit testing and related matters but have used it only on client applications, not on database implemented logic. I recently joined a project whit dozens of PL functions and procedures. So, it would be great for me to find a way to execute unit tests on those functions and pro