Why not create a table with cols a, b, c and d. Where you insert a row for
each combination and key and index abc then return d?
ons. 24. feb. 2021, 21:15 skrev Paul van der Linden <
paul.doskabou...@gmail.com>:
> Thanks for all the suggestions,
>
> When the server is not in use for mission-criti
Thanks for all the suggestions,
When the server is not in use for mission-critical work, I'll definitely
going to do some testing based on your ideas.
Will let you know what comes out of that
Cheers,
Paul
On Thu, Feb 18, 2021 at 6:49 PM hubert depesz lubaczewski
wrote:
> On Thu, Feb 18, 2021 a
Of course it will impact a system using that table, but not significant I
expect and the production system should handle it. If you are committing
like this, then you can kill the script at any time and not lose any work.
The query to find the next IDs to update is probably the slowest part of
this
I am sorry but I am not clear from your response, as I have created
another instance with same version 9.6 but there no system schema or
its tables are visible.
Please help.
On 2/24/21, Francisco Olarte wrote:
> On Wed, Feb 24, 2021 at 12:12 PM Francisco Olarte
> wrote:
>> AFAIK dt list "t
Hello,
Now need to update several million records in a table in prd DB, if can use
batch update 1000 records and commit each time, if it will affect prd
application like below sample script please?
Sample script:
DO $MAIN$
DECLARE
affect_count integer;
chunk_size CONSTANT integer :=1000;
s
Hi,
On Wed, Feb 24, 2021 at 7:50 PM Václav Steiner wrote:
>
> We have three servers running postgres 9.6, master and two slaves feeded by
> streaming replication.
> On of those slaves we are getting different query results. The replica was
> recreated from scratch, but problem persists.
>
> If
On Wed, 2021-02-24 at 12:50 +0100, Václav Steiner wrote:
> We have three servers running postgres 9.6, master and two slaves feeded by
> streaming replication.
> On of those slaves we are getting different query results. The replica was
> recreated from scratch, but problem persists.
>
> If set
Hello.
We have three servers running postgres 9.6, master and two slaves feeded by
streaming replication.
On of those slaves we are getting different query results. The replica was
recreated from scratch, but problem persists.
If set enable_indexscan='off' and set enable_bitmapscan='off' we get
c
On Wed, Feb 24, 2021 at 12:12 PM Francisco Olarte
wrote:
> AFAIK dt list "tables", not "tables in the schemas in search path".
> It states " By default, only user-created objects are shown; supply a
> pattern or the S modifier to include system objects.", but these sys
> schema does not seem to be
Atul:
On Wed, Feb 24, 2021 at 11:24 AM Atul Kumar wrote:
> yes I know that, but my doubt is why \dt is showing tables of other
> schemas even I am setting the search_path.
AFAIK dt list "tables", not "tables in the schemas in search path".
It states " By default, only user-created objects are
On Wed, 2021-02-24 at 15:54 +0530, Atul Kumar wrote:
>
> > > I have postgres 9.6 cluster running on centos 7 machine.
> > > when I set search_path to any user made schema with below command
> > > [enterprisedb@stg-edb02 ~ 01:51:39]$ psql edb
> > > edb=# \c test
> > > set search_path to college;
>
yes I know that, but my doubt is why \dt is showing tables of other
schemas even I am setting the search_path.
Regards,
Atul
On 2/24/21, Thomas Boussekey wrote:
> Hello Atul,
>
> You can use set a filter to limit the tables returned, i.e:
>
> \dt college.*
>
> HTH,
> Thomas
>
>
Hello Atul,
You can use set a filter to limit the tables returned, i.e:
\dt college.*
HTH,
Thomas
Le mer. 24 févr. 2021 à 08:54, Atul Kumar a écrit :
> Hi,
>
> I have postgres 9.6 cluster running on centos 7 machine.
>
> when I set search_path to any user made schema with below command
>
> [e
13 matches
Mail list logo
