On Mon, Sep 15, 2008 at 11:55 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
... so RAM allocation for Pg will prob range between 32MB at the
lower-end and 128MB/196MB at the 1GB recommended RAM.
Assuming a 128MB target, I've been poking and probing with the
postgresql.conf and the new settings
On Mon, Sep 15, 2008 at 12:56 PM, Martin Langhoff
[EMAIL PROTECTED] wrote:
Assuming a 128MB target, I've been poking and probing with the
postgresql.conf and the new settings...
Actually, I misreported the host memory - 128MB is not in the picture
anymore. The minium RAM we expect to operate
Hi,
I am working on the School Server (aka XS: a Fedora 9 spin, tailored
to run on fairly limited hw), I'm preparing the configuration settings
for it. It's a somewhat new area for me -- I've done a lot of tuning
with Pg 7.4 to 8.2 on mid-range hardware (several GBs RAM, RAID
controllers, many
Is it possible to segregate the PITR data by database at any stage? We are
- taking regular (daily) snapshots straight from the disk
- storing WALs
- restoring the snapshot
- replaying the WALs
My guess is that at snapshot time, I could use oid2name to focus on the
database I'm interested
Hi all -
I've spotted the cast-related regressions being discussed here
http://archives.postgresql.org/pgsql-general/2007-11/msg00505.php
... as a Moodle developer supporting Pg, the stricter cast rules in pg
8.3 are somewhat worrying. Is there a straightforward way to configure a
given DB or a
Tom Lane wrote:
Martin Langhoff [EMAIL PROTECTED] writes:
I say they are worrying because Moodle code has many ocurrences of
/* bla.id is an INT8 */
SELECT x,y,z FROM bla WHERE id='1';
And we also often quote INT values for inserts/updates, I am not sure if
this is supported either
On 9/5/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Martin Langhoff escribió:
As I have a Pg install where the locale is already en_US.UTF-8, and
the database already exists, is there a DB-scoped way of controlling
the locale?
Not really.
Ah well. But I do have to wonder why... if each
Hi!
I am having a bit of trouble with indexes, locales and LIKE queries.
Background
--
Using Pg8.1/8.2 on a utf-8 database, my left-anchored LIKE clauses were
forcing a full table scan instead of using the index. After a bit of
digging, I found that Pg can only use the normal index for
Hi!
Background:
Using Pg8.1/8.2 on a utf-8 database, I found out that my left-anchored
LIKE clauses were forcing a full table scan instead of using the
index. After a bit of digging, I found that Pg can only use the
normal index for left-anchored LIKE queries if locale is 'C'.
The optimizer can
Alvaro Herrera wrote:
Martin Langhoff wrote:
# this is apparently the right way to
# select base character based on the equivalence class
# as defined in the LC_CTYPE
=# select * from test where value ~ 'mart[=i=]n';
I think it would be much easier if you did
Alvaro Herrera wrote:
Martin Langhoff wrote:
# this is apparently the right way to
# select base character based on the equivalence class
# as defined in the LC_CTYPE
=# select * from test where value ~ 'mart[=i=]n';
I think it would be much easier if you did
Trying to understand how I can get Pg 8.2 to match 'martÃn' when I
search for 'martin', and going through the documentation, specially
http://www.postgresql.org/docs/8.2/static/locale.html
http://www.postgresql.org/docs/8.1/static/functions-matching.html
Here is a transcript of my
On 4/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Seems overly complicated --- why don't you just shut down the postmaster
and take a tarball archive of the PGDATA tree? Then to revert, stop
postmaster and untar.
Thanks for the tip!
cheers
martin
---(end of
I have been following and experimenting a bit with PITR for a while,
and I wonder whether it is practical to use the PITR hooks to roll
back the database to a known state. The scenario is that I am
developing a script that will be massaging data in a medium size
database. A pg_restore of the
14 matches
Mail list logo
