On 8 Nov 2005, at 16:06, Scott Marlowe wrote:
On Tue, 2005-11-08 at 09:45, Tino Wildenhain wrote:
Alex Stapleton schrieb:
On 8 Nov 2005, at 12:50, Tino Wildenhain wrote:
Evandro's mailing lists (Please, don't send personal messages
to this
address) schrieb:
Hi guys,
I
On 8 Nov 2005, at 12:50, Tino Wildenhain wrote:
Evandro's mailing lists (Please, don't send personal messages to
this address) schrieb:
Hi guys,
I would like to know if it is possible to have more than 1600
columns on windows without recompiling postgres.
I would like to know who on
On 27 Oct 2005, at 16:07, Tom Lane wrote:
Alex Stapleton <[EMAIL PROTECTED]> writes:
The system RAM won't usually be supported by any batteries though, so
it will go crazy, copy corrupt data to the DIMMs on the RAID
controller, which then will refuse to write it to the disk unti
On 27 Oct 2005, at 14:57, Tom Lane wrote:
Alex Stapleton <[EMAIL PROTECTED]> writes:
suspicion is that if the power failure isn't a particularly fast one,
(e.g. you overloaded a fuse somewhere, fuses are insanely slow to
fail compared to alternatives like MCBs) then your RAID card
On 26 Oct 2005, at 19:43, snacktime wrote:
I remember a few months back when someone hit the emergency power
switch to the whole floor where we host at Internap. Subsequently
the backup power system had a cascading failure. Livejournal, who
also hosts there, was up all night and into t
On 22 Oct 2005, at 01:25, Edoceo Lists wrote:
List,
I've got a problem where I need to make a table that is going to
grow by an average of 230,000 records per day. There are only 20
columns in the table, mostly char and integer. It's FK'd in two
places to another table for import/expor
On 18 Oct 2005, at 16:57, Andrew Sullivan wrote:
On Tue, Oct 18, 2005 at 04:37:23PM +0100, Alex Stapleton wrote:
Release a cheaper / free alternative and people will use it because
they will have almost no reason not to. This means that cheaper and
as good as does have a place in the market
On 18 Oct 2005, at 15:59, Andrew Sullivan wrote:
On Sat, Oct 15, 2005 at 05:58:20PM -0700, Chris Travers wrote:
And in the market we're talking
about "cheaper" is not the main consideration for "better than". I
think other arguments are useful -- access to source (and therefore
auditab
Don't forget that MySQL replication also has a habit of silently
failing on you and in my experience needs continuous monitoring to
make sure it actually keeps reasonably up to date (e.g. not days of
data behind on the slaves.)
That was a while ago though, maybe they fixed it?
British Telec
Depending on how your version of PG was built, there will probably be
hardly any difference in speed as far as the CPU is concerned as the
FPU should be happy with both, and I think MMX/MMX2/SSE/SSE2/3dNow!
have some relevant optimisations for that sort of thing as well. You
will be transfe
On 21 Jul 2005, at 17:02, Scott Marlowe wrote:
On Thu, 2005-07-21 at 02:43, vinita bansal wrote:
Hi,
My application is database intensive. I am using 4 processes since
I have 4
processeors on my box. There are times when all the 4 processes
write to the
database at the same time and time
What is everyone's opinion for exclusively using Stored Procedures
for increased security? The scenario I am thinking of means having
one user which is widely accessible (large numbers of staff/user for
example) and only has access to some stored procedures, which where
create with SECURITY
It depends what language you want to sort. Lots of languages do not
have a sort alphabet. For example, Japanese. It can be quite
difficult to sort unusual languages like this. I am not aware of any
standard technique for sorting Japanese text other than keeping an
arbitrarily sorted diction
On 14 Jun 2005, at 14:33, Peter Fein wrote:
Alex Stapleton wrote:
On 13 Jun 2005, at 23:49, Peter Fein wrote:
Hi-
I wanted to use a partially unique index (dependent on a flag) on
a TEXT
column, but the index row size was too big for btrees. See the
thread
"index row size
On 13 Jun 2005, at 23:49, Peter Fein wrote:
Hi-
I wanted to use a partially unique index (dependent on a flag) on a
TEXT
column, but the index row size was too big for btrees. See the thread
"index row size 2728 exceeds btree maximum, 2713" from the
beginning of
this month for someone w
I should point out that theres no garuntee our data is inserted in anything
like the order we want (time desc) but there is a high correlation. Most of
the time it is almost in order.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Alex Stapleton
Sent: 18
Krisztian [mailto:[EMAIL PROTECTED]
Sent: 18 March 2005 10:25
To: Alex Stapleton; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Select Last n Rows Matching an Index Condition
(and caches)
Does not it look like the index you are actually using is on article and
then PG has to filter for symbol and
an Hertroys [mailto:[EMAIL PROTECTED]
Sent: 18 March 2005 09:48
To: Alex Stapleton
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Select Last n Rows Matching an Index Condition
(and caches)
Alex Stapleton wrote:
> SELECT * FROM article WHERE symbol=12646 AND source = 19 ORDER BY time
DESC
We have a ~10million row table but are expecting it to get larger, possibly
by a factor of 10 or more. The rows are quite long and fixed length (just
over 500 bytes.)
We have an index of (symbol, source, date) on this table and doing queries
like this
SELECT * FROM article WHERE symbol=12646 AND
19 matches
Mail list logo
