On Wed, 29 Aug 2007 23:26:06 +0400, Greg Smith <[EMAIL PROTECTED]>
wrote:
First off, posting to two lists like you did (-general and -performance)
is frowned on here. Pick whichever is more appropriate for the topic
and post to just that one; in your case, the performance list would be
m
On Wednesday 29 August 2007, Steve Atkins <[EMAIL PROTECTED]> wrote:
> There are higher end ones that do have ECC RAM (and backup drives and
> stuff) but they're spectacularly more expensive than the cheapo
> consumer ones.
>
Yeah the good ones look more like http://ramsan.com/ .
--
"Pulling tog
In response to Mark Mielke <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > For best performance, the transaction log should be on a separate disk.
> >
> > Does the writing of the log benefit from a battery backed controller
> > as well? If not, what do people think about writing the transact
On Wed, Aug 29, 2007 at 01:11:32PM -0700, Steve Atkins wrote:
> It think the general conclusion was "When they come out with an ECC
> version, we'll look at them."
FWIW, it shouldn't be impossible to implement ECC in software; they'd still
be orders of magnitude faster than normal disks.
/* Stei
On Aug 29, 2007, at 12:54 PM, Mark Mielke wrote:
[EMAIL PROTECTED] wrote:
For best performance, the transaction log should be on a separate
disk.
Does the writing of the log benefit from a battery backed
controller as well? If not, what do people think about writing
the transaction log
[EMAIL PROTECTED] wrote:
For best performance, the transaction log should be on a separate disk.
Does the writing of the log benefit from a battery backed controller
as well? If not, what do people think about writing the transaction
log to a flash card or the like?
How popular are the batter
For best performance, the transaction log should be on a separate disk.
Does the writing of the log benefit from a battery backed controller as well?
If not, what do people think about writing the transaction log to a flash card
or the like?
For best performance, the transaction log should be on a separate disk.
Does
the writing of the log benefit from a battery backed controller as
well? If not, what do people think about writing the transaction log
to a flash card or the like?
First off, posting to two lists like you did (-general and -performance)
is frowned on here. Pick whichever is more appropriate for the topic and
post to just that one; in your case, the performance list would be more
appropriate, and I'm only replying to there.
On Sun, 26 Aug 2007, Max Zorlo
Mark Lewis <[EMAIL PROTECTED]> writes:
> What you probably want to do is tell PG that you're looking for a
> literal underscore and not for any matching character by escaping the
> underscore, that will allow it to do a much quicker index scan.
The other half of the problem is that the planner is
On Wed, 2007-08-29 at 18:01 +0530, Karthikeyan Mahadevan wrote:
>
> *
>
> 1)
>
> EXPLAIN ANALYSE SELECT
> job_category.job_id,job.name,job.state,job.build_id,cat.name as
>
*
1)
EXPLAIN ANALYSE SELECT
job_category.job_id,job.name,job.state,job.build_id,cat.name as
reporting_group
FROM category,job_category,job,category as cat
WHERE job.job_id=job
Thanks Tom,
Exactly what I did, when I realised that there was an extra Table in the
FROM with no conditions set.
Well anyway, this did clear my doubts about whether schema affects
performance at all.
Robins
On 8/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> Schemas are utterly, utterly irre
Hi all,
I'm having a strange performance issue with two almost similar queries, the
one running as expected, the other one taking far more time. The only
difference is that I have "uniid in (10)" in the normally running query and
"uniid in (9,10)" in the other one. The number of rows resulting fro
On 8/28/07, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> >>> On Tue, Aug 28, 2007 at 10:22 AM, in message
> <[EMAIL PROTECTED]>, "Evan Carroll"
> <[EMAIL PROTECTED]> wrote:
> > Yes, I ran vacuum full after loading both dbs.
>
> Have you run VACUUM ANALYZE or ANALYZE?
VACUUM FULL ANALYZE on both tab
Hi all,
I'm having a strange performance issue with two almost similar queries, the
one running as expected, the other one taking far more time. The only
difference is that I have "uniid in (10)" in the normally running query and
"uniid in (9,10)" in the other one. The number of rows resulting fro
Kari Lavikka wrote:
> On Wed, 29 Aug 2007, Heikki Linnakangas wrote:
>
>> The idea of being able to set the toast threshold per column was
>> discussed during 8.3 development, but no patch was produced IIRC. We
>> might do that in the future. If you're willing to compile from source,
>> you can lo
On Wed, 29 Aug 2007, Heikki Linnakangas wrote:
The idea of being able to set the toast threshold per column was
discussed during 8.3 development, but no patch was produced IIRC. We
might do that in the future. If you're willing to compile from source,
you can lower TOAST_TUPLE_THRESHOLD.
We ar
Kari Lavikka wrote:
> It would be nice if I could flag a column to be toasted always,
> regardless of it's length.
The idea of being able to set the toast threshold per column was
discussed during 8.3 development, but no patch was produced IIRC. We
might do that in the future. If you're willing to
Thank you for your answer.
Now i ve to find how to reduce the size of the table.
Paul.
Le mardi 28 août 2007 à 12:55 -0400, Tom Lane a écrit :
> Paul <[EMAIL PROTECTED]> writes:
> > Why in the first case, pgsql uses the "better" index and if i search
> > r_service instead of r_numero pgsql does a
20 matches
Mail list logo
