On Sat, 24 Apr 2021 at 03:44, Ron wrote:
>
> On 4/23/21 10:39 AM, Luca Ferrari wrote:
> > Hi all,
> > this could be trivial, but I would like an explaination: if I turn off
> > sequential scans on a table without indexes, the same access plan is
> > increased by a 100 factor. I suspect
On Fri, Apr 23, 2021, 2:32 AM Mohan Radhakrishnan <
radhakrishnan.mo...@gmail.com> wrote:
> I execute this on the AWS RDS instance. Is there something in the plan I
> should pay attention to ? I notice the Execution Time.
>
>
> " -> Bitmap Index Scan on "testtab_date_brin_idx "
>a) You need to do ANALYZE, otherwise >there are no statistics the
optimizer >could use
I execute and analyze. The actual timestamps I have are not random. I will
order them chronologically.
Thanks
On Saturday, April 24, 2021, Tomas Vondra
wrote:
>
>
> On 4/23/21 10:31 AM, Mohan Radhakrishnan
On 4/23/21 10:31 AM, Mohan Radhakrishnan wrote:
Hi,
I am planning to use as I search based on timestamptz fields.
There are millions of records.I refer
https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits
Eric Hill writes:
> I dont believe we have any unusual extensions. We do have triggers, and the
> VM does have antivirus protection. Ill work on exclusions for the AV, and
> well look into our triggers a bit.
BTW, I happened to check in our commit log to see when we installed the
dead man
Wow, Tom, thanks, that gives us a lot to go on.
The first sign of trouble on the client is just ECONNRESET:
[[37m2021-04-23T07:21:01.073Z[39m] [35m WARN[39m: main/6716 on [redacted]:
[37m[36mPubSub lost connection to datatabase, retrying connection. Error:
read ECONNRESET
at
Hey, Julien,
Yes, I have looked at those instructions and followed them to a T. My data
directory is C:\Program Files\PostgreSQL\11\data as confirmed by SHOW
data_directory;, and I gave the postgres, pgsqladmin, and NETWORK SERVICE
accounts (the latter is the account that is running the
Hi!
On Fri, Apr 23, 2021 at 10:49 AM Francisco Olarte
wrote:
> Of course, I did not follow the thread to deeply, just pointed that in
> case you were assuming that was not going to be stored compressed.
Thanks for pointing that out. I was just trying to make sure I am
understanding you
Mitar:
On Fri, Apr 23, 2021 at 7:33 PM Mitar wrote:
> On Fri, Apr 23, 2021 at 10:28 AM Francisco Olarte
> wrote:
> > A fast look at the link. It seems to be long string of random LOWER
> > CASE HEX DIGITS. A simple huffman coder can probably put it in 5 bits
> > per char, and a more
Hi!
On Fri, Apr 23, 2021 at 10:28 AM Francisco Olarte
wrote:
> A fast look at the link. It seems to be long string of random LOWER
> CASE HEX DIGITS. A simple huffman coder can probably put it in 5 bits
> per char, and a more sophisticated algorithm can probably approach 4.
But this
Just a note:
On Fri, Apr 23, 2021 at 10:57 AM Mitar wrote:
> First, it is important to note that the JSON I am using contains
> primarily random strings as values, so not really something which is
> easy to compress. See example at [1].
A fast look at the link. It seems to be long string of
Eric Hill writes:
> 2021-04-23 03:20:57 EDT [5324]: LOG: connection received: host=10.120.80.162
> port=54017
> 2021-04-23 03:20:57 EDT [5324]: LOG: connection authorized: user=dba_webjmp
> database=webjmp
> 2021-04-23 03:21:00 EDT [15776]: LOG: server process (PID 14820) exited with
> exit
On Fri, Apr 23, 2021 at 03:58:32PM +, Eric Hill wrote:
> Hey,
>
> We are experiencing a periodic PostgreSQL crash. It happens overnight when
> automated processes are updating content on our website. My PostgreSQL
> version information is:
>
> PostgreSQL 11.10, compiled by Visual C++
Hey,
We are experiencing a periodic PostgreSQL crash. It happens overnight when
automated processes are updating content on our website. My PostgreSQL version
information is:
PostgreSQL 11.10, compiled by Visual C++ build 1914, 64-bit
It is running on Windows Server 2019 Standard. We were
On 4/23/21 10:39 AM, Luca Ferrari wrote:
Hi all,
this could be trivial, but I would like an explaination: if I turn off
sequential scans on a table without indexes, the same access plan is
increased by a 100 factor. I suspect this is a warning for me
to remind that something is
Greetings,
* Luca Ferrari (fluca1...@gmail.com) wrote:
> this could be trivial, but I would like an explaination: if I turn off
> sequential scans on a table without indexes, the same access plan is
> increased by a 100 factor. I suspect this is a warning for me
> to remind that something
Hi all,
this could be trivial, but I would like an explaination: if I turn off
sequential scans on a table without indexes, the same access plan is
increased by a 100 factor. I suspect this is a warning for me
to remind that something is misconfigured, or is there anothe reason?
testdb=#
El día viernes, abril 23, 2021 a las 10:48:24a. m. +0200, Laurenz Albe escribió:
> > The serverlog has around this time (sorry for German):
> >
> > 2021-04-23 05:55:23.591 CEST [2317] LOG: unvollständige Message vom Client
> > 2021-04-23 05:55:23.593 CEST [2317] FEHLER: Speicher aufgebraucht
>
Hi!
On Thu, Apr 15, 2021 at 12:11 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > My point was that for JSON, after validating that the input is
> > syntactically correct, we just store it as-received. So in particular
> > the amount of whitespace in the value would depend on how the client
Am Fri, Apr 23, 2021 at 10:48:24AM +0200 schrieb Laurenz Albe:
> > The serverlog has around this time (sorry for German):
> >
> > 2021-04-23 05:55:23.591 CEST [2317] LOG: unvollständige Message vom Client
> > 2021-04-23 05:55:23.593 CEST [2317] FEHLER: Speicher aufgebraucht
> > 2021-04-23
On Fri, 2021-04-23 at 10:15 +0200, Matthias Apitz wrote:
> We face (somehow reproducible) the following situation with a 13.1
> server and a client written in ESQL/C:
>
> # ps ax | grep post
> ...
> 27106 ?Ss 0:00 postgres: sisis sisis ::1(49518) idle in
> transaction
>
> # lsof |
Hi,
I am planning to use as I search based on timestamptz fields.
There are millions of records.I refer
https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits
I execute this on the AWS RDS instance. Is there something in the plan I
should pay attention
Hello,
We face (somehow reproducible) the following situation with a 13.1
server and a client written in ESQL/C:
# ps ax | grep post
...
27106 ?Ss 0:00 postgres: sisis sisis ::1(49518) idle in transaction
# lsof | grep 49518
INDEX 27074 sisis2u
23 matches
Mail list logo
