Hi
I need some top 10 customers list in financial or healthcare domain (
irrespective of open-source or proprietary tool )
We need to showcase to our customer for building analytical database
Please do share, it will be really helpful
Thanks
Sridhar BN
On 2015-08-18 20:40:10 +0900, Masahiko Sawada wrote:
> On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer wrote:
> > It looks like the catalog version has changed between 9.5alpha1 and
> > 9.5alpha2:
[...]
> > So, what's the best way to do the upgrade?
> >
> > * Copy the bindir before the upgrade (o
On 8/18/2015 6:33 AM, Joseph Kregloh wrote:
Of course not every machine is built the same and not every PostgreSQL
server is used the same, to tune according to the machine and the
usage of the server.
indeed, your use case heavily affects the optimal decisions, there's no
one-size-fits-all
Joshua D. Drake wrote:
>
> On 08/18/2015 09:41 AM, Alvaro Herrera wrote:
> >
> >Alvaro Herrera wrote:
> >
> >>One thing to look at is the rate of WAL generation for a set number of
> >>transactions. Maybe the later releases are generating more WAL due to
> >>multixacts, for instance (prior to 9.3
I wrote:
> One thing to look at is the rate of WAL generation for a set number of
> transactions. Maybe the later releases are generating more WAL due to
> multixacts, for instance (prior to 9.3 these weren't wal-logged.)
FWIW a very easy way to measure this is to look at the output of
"pg_xlogd
On 08/18/2015 09:41 AM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
One thing to look at is the rate of WAL generation for a set number of
transactions. Maybe the later releases are generating more WAL due to
multixacts, for instance (prior to 9.3 these weren't wal-logged.)
Also try 9.5alp
Alvaro Herrera wrote:
> One thing to look at is the rate of WAL generation for a set number of
> transactions. Maybe the later releases are generating more WAL due to
> multixacts, for instance (prior to 9.3 these weren't wal-logged.)
Also try 9.5alpha2, wherein bug #8470 is fixed, which is a bi
Joshua D. Drake wrote:
>
> On 08/18/2015 09:19 AM, Melvin Davidson wrote:
> >>8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
> > >>shared_buffers=60GB
> >
> >I would say 60GB is too high when you have 128GB system memory.
> >Try lowering it to shared_buffers=32GB and let the O/S han
On 08/18/2015 09:19 AM, Melvin Davidson wrote:
8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
>>shared_buffers=60GB
I would say 60GB is too high when you have 128GB system memory.
Try lowering it to shared_buffers=32GB and let the O/S handle more of
the work.
I would also loo
>8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
>>shared_buffers=60GB
I would say 60GB is too high when you have 128GB system memory.
Try lowering it to shared_buffers=32GB and let the O/S handle more of the
work.
On Tue, Aug 18, 2015 at 11:49 AM, Jeff Janes wrote:
> On Tue, Aug
On Tue, Aug 18, 2015 at 8:01 AM, Michael H wrote:
> Hi,
>
> I've been tuning our new database server, here's some info...
>
> CentOS Linux release 7.1.1503 (Core)
> 3.10.0-229.11.1.el7.x86_64
>
> 8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
> 2 x AMD Opteron 6386SE 2.8GHz/16-core
Here are the only things that I amended, all other settings are defaults.
maintenance_work_mem=2GB
checkpoint_segments=64
wal_keep_segments=128
max_prepared_transactions=10
max_wal_senders=3
wal_level=hot_standby
max_files_per_process=100
max_stack_depth=7MB
On 08/18/2015 08:01 AM, Michael H wrote:
Hi,
I've been tuning our new database server, here's some info...
CentOS Linux release 7.1.1503 (Core)
3.10.0-229.11.1.el7.x86_64
8 x 16GB 1600MHz PC3-12800 DDR3- 128GB total
2 x AMD Opteron 6386SE 2.8GHz/16-core/140w - 32 cores total
Hi,
I've been tuning our new database server, here's some info...
CentOS Linux release 7.1.1503 (Core)
3.10.0-229.11.1.el7.x86_64
8 x 16GB 1600MHz PC3-12800 DDR3 - 128GB total
2 x AMD Opteron 6386SE 2.8GHz/16-core/140w - 32 cores total
4 x 300GB SAS 10k HDD
On 08/18/2015 07:11 AM, Tom Lane wrote:
Adrian Klaver writes:
On 08/18/2015 06:44 AM, Tom Lane wrote:
Adrian Klaver writes:
The only thing I can think to do is load pg_stat_statements:
http://www.postgresql.org/docs/9.4/interactive/pgstatstatements.html
That won't help after-the-fact eith
Adrian Klaver writes:
> On 08/18/2015 06:44 AM, Tom Lane wrote:
>> Adrian Klaver writes:
>>> The only thing I can think to do is load pg_stat_statements:
>>> http://www.postgresql.org/docs/9.4/interactive/pgstatstatements.html
>> That won't help after-the-fact either.
> Well at some point the q
On 08/18/2015 06:44 AM, Tom Lane wrote:
Adrian Klaver writes:
On 08/18/2015 01:43 AM, Mikhail wrote:
I have a long executing query via foreign data wrapper and on the remote
server i can see that the query is fetching data from the cursor
...
Is it possible to get query text corresponding to c
Adrian Klaver writes:
> On 08/18/2015 01:43 AM, Mikhail wrote:
>> I have a long executing query via foreign data wrapper and on the remote
>> server i can see that the query is fetching data from the cursor
>> ...
>> Is it possible to get query text corresponding to cursor c514?
> The only thing
When tuning the last server that we built I followed the following Wiki
page as to where to make adjustments
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server then tested
the tweaks using pgbench tools from
https://github.com/gregs1104/pgbench-tools. Of course not every machine is
buil
On 08/18/2015 01:43 AM, Mikhail wrote:
Hi,
I have a long executing query via foreign data wrapper and on the remote
server i can see that the query is fetching data from the cursor
=# select application_name, state, query from pg_stat_activity where pid
= 15455;
application_name │ state │ query
On Tue, Aug 18, 2015 at 1:00 PM, Jimit Amin wrote:
> Can I know normal, aggressive, best parameter settings for PostgreSQL.conf
> file for particular hardware.
>
> Like Linux x86_64 , 8 GB Ram
> , Linux x86_64 , 126 GB Ram
There's no generic answer because it depends on what you're doing with
the
On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer wrote:
> It looks like the catalog version has changed between 9.5alpha1 and
> 9.5alpha2:
>
> FATAL: database files are incompatible with server
> DETAIL: The database cluster was initialized with CATALOG_VERSION_NO
> 201506282,
> but
2015-08-18 7:08 GMT-03:00 Mitu Verma :
> Hi,
>
> I need to delete following threads posted by me on postgreSQL forum,
>
> Kindly suggest me a way forward as it is urgent.
FYI, see note 1 [1] in the subscribe page [2].
[1] https://wiki.postgresql.org/wiki/Archives_Policy
[2] http://www.postgresql
Dear all,
Can I know normal, aggressive, best parameter settings for PostgreSQL.conf
file for particular hardware.
Like Linux x86_64 , 8 GB Ram
, Linux x86_64 , 126 GB Ram
Thanks and Regards
Jimit Amin
On 8/18/2015 3:08 AM, Mitu Verma wrote:
I need to delete following threads posted by me on postgreSQL forum,
Kindly suggest me a way forward as it is urgent.
good luck with that.email is write-only
the postgres mailing lists are archived on dozens and dozens of
different systems
--
Hi,
I need to delete following threads posted by me on postgreSQL forum,
Kindly suggest me a way forward as it is urgent.
http://www.postgresql.org/message-id/84bc7ab0d621a74893ec9c9e151293b022685...@esessmb207.ericsson.se
http://osdir.com/ml/postgresql-pgsql-general/2015-04/msg00543.html
http
Hi,
If my system RAM is 50 GB then how can I tune my database server without
using the Thumb rule of postgresql.conf parameter like:
Shared_buffer: 25% of the RAM
temp_buffers: should be default
work_mem: AvRAM/2 * Max_connections
etc...
There is any another way or any other rule or Tool which c
It looks like the catalog version has changed between 9.5alpha1 and
9.5alpha2:
FATAL: database files are incompatible with server
DETAIL: The database cluster was initialized with CATALOG_VERSION_NO
201506282,
but the server was compiled with CATALOG_VERSION_NO 201507281.
HINT: It
Hi All,
I've asked recently about amending the stack depth for system services
in centos7, namely LimitSTACK for increasing max_stack_depth parameter.
Below is the answer to my question provided on the CentOS mailing list,
I'm posting here to share the information.
On 17/08/15 19:07, Gordon
Hi,
I have a long executing query via foreign data wrapper and on the remote server
i can see that the query is fetching data from the cursor
=# select application_name, state, query from pg_stat_activity where pid =
15455;
application_name │ state │ query
──┼┼─
30 matches
Mail list logo
