Hi Dmitry，
I think this a wonderful idea, but it will be tough. Share my experience:
—dbeaver:
It is for multi-platform so it is just for use, no particular function,
also there is more bugs(our company had changed some of them).
dbeaver is likely the most open source app form pg
Hi, we have a logical backup process that runs every night since 5+ years.
It is a logical backup we use to restore a non production environment. We
use pg_dump in parallel mode in directory format.
Postgres version is 9.6.6
Tonight schedule failed with the following error:
pg_dump: [archiver
Greetings Vick,
* Vick Khera (vi...@khera.org) wrote:
> I didn't know it existed either, mostly because I know how to ask google to
> do things, and the things I need to know are not covered here (yet). This
> does seem to me to be the ideal place to add more how to documentation to
> augment all
On 07/18/2018 10:43 AM, Andreas Kretschmer wrote:
>
>
> Am 18.07.2018 um 10:26 schrieb Hans Schou:
>> Am I doing something wrong or should some history be cleared?
>
> Reset the stats for that database. You can check the date of last reset
> with:
>
> select stats_reset from pg_stat_database wh
> Hi, I have also reported a similar problem in the hackers mailing list,
but particularly on TRUNCATE TABLE.
https://www.postgresql.org/message-id/flat/D09B13F772D2274BB348A310EE3027C62FD6E6%40g01jpexmbkw24
Ooh, interesting. I admit I did not include TRUNCATE in my testing.
> The problem lies wi
> There was a recent commit for a similar performance problem, which will
appear in 9.6.10. But that was specifically for cases where there were
multiple dropped tables per transaction, and large shared_buffers.
Interesting, and good to know, thanks! I'm not sure we fall under either
(is 8 GB lar
Now to the list...
> >> I'm trying to compile PostgreSQL 11beta2 but this errors occur:
> >> checking readline.h usability... no
>
> > Looks like you need whatever is the FreeBSD equivalent of readline-
> dev(el).
>
> AFAICT FreeBSD doesn't do things that way. On a nearby machine, I see
>
Hi Vikas,
For the postgres service, we have the same case (each cluster members has
different minor version of 9.6) and there is no problem with that.
But be careful about extensions. Because sometimes an extension can require
an upgrade in its db structure otherwise it won't work. So if there is a
Hi All,
We have Postgresql 9.5 Cluster with streaming replication and pgpool. The
version of Postgres is 9.5.5 and Pgpool-II version 3.2.15.
There is now hardware issue with the Standby Machine and it won't startup
so we are building new Standby machine.
My question is about the minor version of
On 07/18/2018 06:57 AM, Thomas Kellerer wrote:
Adrian Klaver schrieb am 18.07.2018 um 15:06:
In the chapter "Database File layout" the pgsql_tmp is explained as follows:
Temporary files (for operations such as sorting more data than can fit in
memory)
are created within PGDATA/base/p
Thomas Kellerer writes:
> But what about the (temp) space needed for e.g. sorting, grouping or
> intermediate results from CTEs or derived tables?
> Is that also controlled through the temp_tablespaces?
Yes.
regards, tom lane
Adrian Klaver schrieb am 18.07.2018 um 15:06:
>> In the chapter "Database File layout" the pgsql_tmp is explained as follows:
>>
>> Temporary files (for operations such as sorting more data than can fit
>> in memory)
>> are created within PGDATA/base/pgsql_tmp, or within a pgsql_tmp
>> su
On 07/18/2018 02:13 AM, Raghavendra Rao J S V wrote:
We have thousands of tables. But out of those tables, around 20 to 40
tables are always busy due to that those tables are bloating.
Define bloating?
In order to avoid this we are running a shell script which performs
vacuum full on the ta
On 07/18/2018 12:53 AM, Thomas Kellerer wrote:
In the chapter "Database File layout" the pgsql_tmp is explained as follows:
Temporary files (for operations such as sorting more data than can fit in
memory)
are created within PGDATA/base/pgsql_tmp, or within a pgsql_tmp
subdirectory of
Hi Raghavendra
answers in line here below:
On 18/07/18 11:13, Raghavendra Rao J S V wrote:
> We have thousands of tables. But out of those tables, around 20 to 40 tables
> are always busy due to that those tables are bloating.
>
> In order to avoid this we are running a shell script which perf
On Wed, Jul 18, 2018 at 10:44 AM Andreas Kretschmer
wrote:
>
> ||pg_stat_reset()
>
Thanks, I guess we can see the result in a few days.
BTW, strang command: it only reset current database and it can't take db as
parameter.
We have thousands of tables. But out of those tables, around 20 to 40
tables are always busy due to that those tables are bloating.
In order to avoid this we are running a shell script which performs vacuum
full on the tables which has more than ten thousand dead tuples. While
running this we are
Am 18.07.2018 um 10:26 schrieb Hans Schou:
Am I doing something wrong or should some history be cleared?
Reset the stats for that database. You can check the date of last reset
with:
select stats_reset from pg_stat_database where datname = 'database_name';
and reset it with:
||pg_stat_r
Hi
I have this system with some databases and I have run the
cache_hit_ratio.sql script on it. It showed that the db acme777booking had
a ratio on 85%. I then changed shared_buffer size from 0.5GB to 4GB as the
server has 16GB of physical RAM. After 6 days of running I checked the
ratio again and
In the chapter "Database File layout" the pgsql_tmp is explained as follows:
Temporary files (for operations such as sorting more data than can fit in
memory)
are created within PGDATA/base/pgsql_tmp, or within a pgsql_tmp subdirectory
of
a tablespace directory
However the documentat
20 matches
Mail list logo
