On 2021-01-22 10:22, Zwettler Markus (OIZ) wrote:
>>
>> On Fri, 2021-01-15 at 14:09 +, Zwettler Markus (OIZ) wrote:
>>> I want to use ldap to lookup the connection parameters:
>>> https://www.postgresql.org/docs/12/libpq-ldap.html
>>>
>>> or is there also some kind of generic variant like this
>I wonder how hard it would be to hack up a table access method that is
just a copy of heap where HEAP_INSERT_SKIP_FSM is always set...
Update: I think this actually works. It's awful because I just copied the
entire builtin heap code into an extension and then renamed a few functions
so they don'
On a whole fleet of load-balanced replicas, we saw an incident where one
particular query started backing up on MultiXactMemberControlLock and
multixact_member. There was no sign of this backup on the primary. Under what
conditions would there be enough multixact members on a replica (where yo
I'm experimenting with that right now. Setting storage to MAIN appears to
be counterproductive, whereas EXTERNAL with toast_tuple_target = 128 is
definitely an improvement. In theory, this configuration might eliminate
the problem, but due to the toast_tuple_target bug (
https://www.postgresql.org/
If you have no updates or deletes, then I would wonder about setting
fillfactor LOWER such that new rows are less likely to find a gap that is
acceptable. Depending how/when you use the json, lowering
toast_tuple_target may be appropriate to store (nearly?) all out of line
and making the data store
This is on version 12.5. The usage pattern is inserts only, no updates or
deletes at all. Hence, fillfactor is set to 100.
It just seems extremely unfortunate in this particular case that Postgres
goes to all the trouble of tetris-ing new tuples into existing pages, only
to cripple performance in
What version are you using? What is your usage pattern for
insert/update/deletes? If sometimes the JSON data gets too big and the data
is moved from in-line storage to TOASTED, then that would be opening up
gaps. Or if you are doing deletes. Perhaps adjusting your fillfactor
and/or TOAST_TUPLE_TARG
Matthias Apitz writes:
> I've read the doc https://www.postgresql.org/docs/13/kernel-resources.html
> but I'm still relatively clueless, what to set.
For modern PG versions on Linux, you basically shouldn't ever have to
touch those numbers. I'd only start to worry if I saw server startup
failure
Hello,
I am working on a system to store and analyze JSON-based log data. The idea
is to store tuples with a monotonically increasing timestamp (i.e.
CURRENT_TIMESTAMP) in a table and run some queries that focus on specific
time windows (~one hour). It seems to me that a BRIN index is designed
exa
On 12/02/2021 4:33 am, Thorsten Schöning wrote:
If you see that somewhat frequently, use Process Monitor and Process
Explorer to see who accesses those files how. ProcExp easily allows
you to find all open handles per file. If it's not AV, it might be
something like Windows Search Indexer as well
On 12/02/2021 12:31 am, Lionel Bouton wrote:
I haven't dealt with a Windows environment for quite some time, but from
what I remember an antivirus installs a driver intercepting file
accesses and these drivers are still active even if you disable the
antivirus (I suppose they just call a noop ins
> De: "Luca Ferrari"
> Para: "pgsql-general"
> Enviadas: Sexta-feira, 12 de fevereiro de 2021 8:00:46
> Assunto: pg_stat_progress_vacuum empty when running vacuum full
> Hi all,
> I'm running 11.5 and I'm monitoring pg_stat_progress_vacuum every 2
> seconds, while doing from another connection
2021年2月12日(金) 20:01 Luca Ferrari :
> Hi all,
> I'm running 11.5 and I'm monitoring pg_stat_progress_vacuum every 2
> seconds, while doing from another connection per-table VACUUMs. Every
> vacuum last 30 or more seconds, so I was expecting to see a record
> within pg_stat_progress_vacuum, but noth
Hi all,
I'm running 11.5 and I'm monitoring pg_stat_progress_vacuum every 2
seconds, while doing from another connection per-table VACUUMs. Every
vacuum last 30 or more seconds, so I was expecting to see a record
within pg_stat_progress_vacuum, but nothing appears if the vacuum is
full. I suspect t
Hello,
I've read the doc https://www.postgresql.org/docs/13/kernel-resources.html
but I'm still relatively clueless, what to set. For example for our
standard installations like
- RAM: 32 GByte
- one PostgreSQL 13.1 server
- one database with ~400 tables, 4 GByte in size
- 100-200 connecting Po
15 matches
Mail list logo
