Jeff Amiel becauseimj...@yahoo.com writes:
At the moment I think the only way to work around this is
to denormalize
your schema a bit.
And I feared as much.
It's biting me in other areas as well...this unusual distribution of
data...certain types of customers have completely different
For a PostgreSQL 9.1.1 instance,
I have used the following postgresql.conf settings:
max_connections = 100
shared_buffers = 400MB
wal_buffers = 16MB
All the other parameters have been left as default values.
When I startup the instance, I get an error message
saying that the shared memory does
On 2.12.2011 09:16, Oleg Serov wrote:
Hello!
i've don't try to do reindex. There was enough space.
Not sure whether you tried to reindex or not. And what do you mean by
'there was enough space'? For example with ext2 (and ext3/ext4) it was
rather simple to exhaust inodes long before the
On 3.12.2011 13:39, Christoph Zwerschke wrote:
For a PostgreSQL 9.1.1 instance,
I have used the following postgresql.conf settings:
max_connections = 100
shared_buffers = 400MB
wal_buffers = 16MB
All the other parameters have been left as default values.
When I startup the instance, I
Marti Raudsepp schrieb:
On Fri, Dec 2, 2011 at 16:16, Torsten Zuehlsdorff
f...@meisterderspiele.de wrote:
But i clearly have a missunderstanding of other chars, like umlauts or utf-8
chars. This, for example, should return a 'ö':
# SELECT chr(x'C3B6'::int);
chr
-
쎶
(1 row)
That gives
I think, the main problem is that, postgres reads wrong xlog-s file.
I lunched strace to postgres process, and then i grep the log:
# cat /tmp/strace-log | fgrep xlog
5546 stat(pg_xlog, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
5546 stat(pg_xlog/archive_status, {st_mode=S_IFDIR|0700,
Am 03.12.2011 15:34, schrieb Tomas Vondra:
Do you need to know an exact value or are you just interested why the
values in docs are not exact?
Both. I'm writing an installation script that calculates the necessary
IPC memory and increases the limit on the OS level (kernel.shmmax) if
needed.
Christoph Zwerschke c...@online.de writes:
... This is a discrepancy of 1.25%.
The difference could be explained by taking credit for the descriptors
which may not be comprised in the shared_buffers setting, even if the
shared_buffers value is set in memory units. But according to the docs,
Hello friends,
I am checking some logic which includes two functions. One is plsql
function which returns text. Second function is plpythonu and contains one
statement which outputs notice
e.g.
results = plpy.execute(select * from software.func1();)
plpy.notice(%s % col for col in results[0])
CP - You're missing a line in the middle; one which will extract specific
content(s) from $results.
Because, yes, without such a line, python will only return the object
reference.
Lou Picciano
- Original Message -
From: c k shreeseva.learn...@gmail.com
To: pgsql-admin
can you please give me the example
I am not a python programmer.
C P Kulkarni
On Sat, Dec 3, 2011 at 11:25 PM, Lou Picciano loupicci...@comcast.netwrote:
CP - You're missing a line in the middle; one which will extract specific
content(s) from $results.
Because, yes, without such a line,
when I modified the notice statement as
plpy.notice('%s' %results[0])
it prints notice as
NOTICE: {'func1': 'function return text'}
I didn't understand why it is showing 'func1' in the results[0] ?
C P Kulkarni
On Sat, Dec 3, 2011 at 11:31 PM, c k shreeseva.learn...@gmail.com wrote:
can
Am 03.12.2011 18:02, schrieb Christoph Zwerschke:
The difference could be explained by taking credit for the descriptors
which may not be comprised in the shared_buffers setting, even if the
shared_buffers value is set in memory units.
Looked a bit more into this - the shared_buffers setting
Am 03.12.2011 18:39, schrieb Tom Lane:
The long and the short of it is those numbers aren't meant to be
exact. If they were, we'd have to complicate the table to distinguish
32 vs 64 bit and possibly other factors, and we'd have to remember to
re-measure the values after any code change, neither
# Assuming your query here returns col1, col2, etc.:
results = plpy.execute(select * from software.func1();)
# these lines will return the results --
# - (where the first member of the array is the 'row number' of the result:)
value1 = results[0][ col1 ]
value2 = results[0][ col2 ]
Am 03.12.2011 13:39, schrieb Christoph Zwerschke:
According to that table the usage would be:
Connections: 1908000 Bytes
Autovac workers: 57240 Bytes
Prepared transactions: 0 Bytes
Shared disk buffers: 400MB
WAL buffers: 16MB
Fixed space: 788480 Bytes
Sum: 435145336
This is about 16MB less than
thanks.
it solved my problem.
C P Kulkarni
On Sun, Dec 4, 2011 at 12:21 AM, Lou Picciano loupicci...@comcast.netwrote:
# Assuming your query here returns col1, col2, etc.:
results = plpy.execute(select * from software.func1();)
# these lines will return the results --
# - (where
On Thu, Dec 1, 2011 at 6:46 AM, Adarsh Sharma adarsh.sha...@orkash.com wrote:
I have a position table that contains the lat lon of an entity from time to
time.
Now I want to get the place names from the respective lat lon.
You might want to try the PostGIS lists instead.
Josh
--
Sent via
Am 03.12.2011 20:31, schrieb Christoph Zwerschke:
Then, the corrected sum is 449627320 Bytes, which is only about 2MB less
than was requested. This remaining discrepancy can probably be explained
by additional overhead for a PostgreSQL 9.1 64bit server vs. a
PostgreSQL 8.3 32bit server for which
Am 03.12.2011 18:02, schrieb Christoph Zwerschke:
400 MB = 419430400 Bytes
but according to your log the used memory is:
buffers = 424669472 Bytes
This is a discrepancy of 1.25%.
The difference could be explained by taking credit for the descriptors
which may not be comprised in the
20 matches
Mail list logo
