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 shared_bu
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
On Thu, Dec 1, 2011 at 6:46 AM, Adarsh Sharma 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 pgsql-general mailing l
thanks.
it solved my problem.
C P Kulkarni
On Sun, Dec 4, 2011 at 12:21 AM, Lou Picciano wrote:
> # 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
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
# 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][ "col
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
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 in
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 wrote:
> can you please give me the example
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 wrote:
> 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 retu
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"
To: "pgsql-admin" , pgsql-general@postgresql.org
Sent
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])
Christoph Zwerschke 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,
> the des
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.
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, s
Marti Raudsepp schrieb:
On Fri, Dec 2, 2011 at 16:16, Torsten Zuehlsdorff
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 you the Unicode codepoint
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 in
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 dev
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
Jeff Amiel 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 data patterns
> t
20 matches
Mail list logo
