Our developers like the dblink modules, so I have installed it into the
template1 database. They also like to import old database dumps after
creating new databases with dbcreate. But then they get irritated by the
error messages saying that the dblink functions already exist, because
these fun
Am 04.12.2011 15:17, schrieb sfr...@snowman.net:
Didn't see this get answered... The long-and-short of that there aren't
any negative consequences of having it higher, as I understand it
anyway, except the risk of greedy apps. In some cases, shared memory
can't be swapped out, which makes it a
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
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 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
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
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.
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
Am 10.05.2010 23:34 schrieb Alban Hertroys:
> Thinking more on the issue, I don't see a way to prevent the nested
> loop as there's no way to decide beforehand what part of the string to
> index for b.txt. It depends on a.txt after all.
Yes, that seems to be the gist of the matter. I just felt I
Am 10.05.2010 11:50 schrieb Alban Hertroys:
> On 10 May 2010, at 24:01, Christoph Zwerschke wrote:
>
>> select * from b join a on b.txt like a.txt||'%'
>>
>> I feel there should be a performat way to query these entries,
>> but I can't come up wit
Assume we have a table "a" with a text column "txt"
and an index on that column.
A query like the following will then be very perfomant
since it can use the index:
select * from a where txt like 'a%'
(Assume also that the server is using the C locale or the index
is set up with text_pattern_ops
12 matches
Mail list logo
