550742-07
query_start | 2016-03-18 14:44:22.550742-07
state_change | 2016-03-18 14:44:22.550746-07
waiting | f
state| active
backend_xid |
backend_xmin | 58635
query| select * from pg_stat_activity;
Thanks
Avi
--
Adrian Klaver
adrian.kla...@ak
On 02/20/2016 10:39 AM, Francisco Olarte wrote:
On Sat, Feb 20, 2016 at 7:13 PM, Adrian Klaver
wrote:
.
FROM
sym_data d INNER JOIN sym_data_gap g ON g.status = 'GP'
AND d.data_id BETWEEN g.start_id
AND g.end_id
.
The thing that stands out to me is that I
ents = 256
wal_level = hot_standby
max_wal_senders = 5
wal_keep_segments = 256
random_page_cost = 3.5
autovacuum_vacuum_threshold = 1000
autovacuum_analyze_threshold = 250
max_locks_per_transaction = 2000
When I check taskmanager, I found postgres process is user 4-5MB
What happened with my PostgreSQL. Please help me
On 12/08/2014 01:22 PM, Tom Lane wrote:
Adrian Klaver writes:
I redid the test on my 32-bit machine, setting work_mem=16MB, and I got
comparable results to what I saw on the 64-bit machine. So, what I am
still am puzzled by is why work_mem seems to make the two paths
equivalent in time?:
If
On 12/08/2014 12:53 PM, Tom Lane wrote:
> I wrote:
>> Adrian Klaver writes:
>>> Seems work_mem is the key:
>
>> Fascinating. So there's some bad behavior in the lossy-bitmap stuff
>> that's exposed by one case but not the other.
>
> Meh. I
as the server?
issue: psql client generates a core when up arrow is used twice.
Regards
Tarkeshwar
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
nsert? and anything related to performance
See bottom of above page and here:
http://www.postgresql.org/docs/9.1/static/trigger-definition.html
thank you
have a sunny day
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresq
