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
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
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 spi
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
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 i
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
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.
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 c
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
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
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
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 commandline
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 broadcast)
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 prist
14 matches
Mail list logo
