--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Brian Herlihy <[EMAIL PROTECTED]> writes:
> > My options seem to be
> > - Fudge the analysis results so that the selectivity estimate changes. I
> > have tested reducing n_distinct, but this doesn't seem to help.
> > - Combine the columns into one col
Brian Herlihy <[EMAIL PROTECTED]> writes:
> My options seem to be
> - Fudge the analysis results so that the selectivity estimate changes. I
> have tested reducing n_distinct, but this doesn't seem to help.
> - Combine the columns into one column, allowing postgres to calculate the
> combined
--- Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > To: pgsql-performance@postgresql.org
> > Subject: Re: [PERFORM] Query planner is using wrong index.
> [Snip]
> > I am really surprised that I have to go through such contortions just
> to
> > use
> > the primary key! T
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:pgsql-performance-
> [EMAIL PROTECTED] On Behalf Of Brian Herlihy
> Sent: Thursday, April 06, 2006 6:56 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Query planner is using wrong index.
[Snip]
> I am really surpri
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fös, 2006-04-07 at 00:01 +1000, Brian Herlihy wrote:
> > Index Scan using p2_p3_idx on t (cost=0.00..6.02 rows=1 width=102)
> (actual
> > time=2793.247..2793.247 rows=0 loops=1)
> >Index Cond: (((p2)::text = 'uk.altavista.com'::text) AND ((p3)::tex
For a DSS type workload with PostgreSQL where you end up with single
long running queries on postgresql with about 100GB, you better use
something like Sun Fire V40z with those fast Ultra320 internal drives.
This might be perfect low cost complete database in a box.
Sun Fire T2000 is great for
Hi Leigh
inline comments
Leigh Dyer wrote:
Luke Lonergan wrote:
Juan,
We've got a Sun Fire V40z and it's quite a nice machine -- 6x 15krpm
drives, 4GB RAM, and a pair of Opteron 850s. This gives us more than
enough power now for what we need, but it's nice to know that we can
shoehorn
On Apr 6, 2006, at 10:48 AM, Kaloyan Iliev wrote:
If I use cursors it's better but my problem is that cursors live
only in the current transaction.
So when the Web Server finish I've lost the transaction and the
cursor.
Cursors can live outside the transaction if you declare them WITH
H
On fös, 2006-04-07 at 00:01 +1000, Brian Herlihy wrote:
> --- Ragnar <[EMAIL PROTECTED]> wrote:
>
> > On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
> >
> > > Yes, the primary key is far better. I gave it the ultimate test - I
> > dropped
> > > the (p2, p3) index. It's blindingly fast
Juan,
On 4/6/06 7:01 AM, "Matthew Nuzum" <[EMAIL PROTECTED]> wrote:
>> Apart from that since I will only get this one chance to
>> buy a new server for data processing I need to make sure that I buy
>> something that can grow over time as our needs change. I don't want to
>> buy a server only to
On Apr 6, 2006, at 12:47 AM, Leigh Dyer wrote:
I'm sure those little SAS drives would be great for web servers and
other non-IO-intensive tasks though -- I'd love to get some X4100s
in to replace our Poweredge 1750s for that. It's a smart move
overall IMHO,
For this purpose, bang for the
On Apr 5, 2006, at 9:11 PM, Marcelo Tada wrote:
What are you think about the Sun Fire X64 X4200 Server?
I use the X4100 and like it a lot. I'm about to buy another. I see
no advantage to the X4200 unless you want the extra internal disks.
I use an external array.
---
On Apr 5, 2006, at 5:58 PM, August Zajonc wrote:
Most involve some AMD Opertons, lots of spindles with a good raid
controller preferred to one or two large disks and a good helping of
ram. Be interesting to get some numbers on the sunfire machine.
I can highly recommend the SunFire X4100, how
Hi,
I am working on Web Based application using Perl and Apache.
I have to show to the users some query results by pages.
Some time the result can be over 1000 rows (but can be more).
The question is how to make this.
The one way is to use OFFSET and LIMIT. That's OK but every time the
whole qu
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
>
> > Yes, the primary key is far better. I gave it the ultimate test - I
> dropped
> > the (p2, p3) index. It's blindingly fast when using the PK,
>
> I have problems understanding exactly how an
On 4/6/06, Juan Casero (FL FLC) <[EMAIL PROTECTED]> wrote:
> Because I plan to develop a rather large (for us anyway) data warehouse
> with PostgreSQL. I am looking for the right hardware that can handle
> queries on a database that might grow to over a 100 gigabytes.
You need to look for a serve
On Apr 5, 2006, at 6:07 PM, Jim Nasby wrote:
More importantly, it allows the system to come up and do fsck in
the background. If you've got a large database that's a pretty big
benefit.
That's a UFS2 feature, not a soft-updates feature.
---(end of broadcast)
> > On 3/22/06 5:56 AM, "Spiegelberg, Greg" <[EMAIL PROTECTED]> wrote:
> >
> > > Has anyone tested PostgreSQL 8.1.x compiled with Intel's Linux C/C++
> > > compiler?
> >
> > We used to compile 8.0 with icc and 7.x before that. We found very good
> > performance gains for Intel P4 architecture proc
On fim, 2006-04-06 at 19:27 +1000, Brian Herlihy wrote:
> --- Ragnar <[EMAIL PROTECTED]> wrote:
>
> > On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
> >
...
> > > PRIMARY KEY (p1, p2, p3)
...
> > >
> > > I have also created an index on (p2, p3), as some of my lookups are on
> > > these
Because I plan to develop a rather large (for us anyway) data warehouse
with PostgreSQL. I am looking for the right hardware that can handle
queries on a database that might grow to over a 100 gigabytes. Right
now our decision support system based on postgresql 8.1.3 stores retail
sales informati
--- Ragnar <[EMAIL PROTECTED]> wrote:
> On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
>
> > I have a problem with the choice of index made by the query planner.
> >
> > My table looks like this:
> >
> > CREATE TABLE t
> > (
> > p1 varchar not null,
> > p2 varchar not null,
> >
Hi, Juan,
Juan Casero (FL FLC) wrote:
> Ok that is beginning to become clear to me. Now I need to determine if
> this server is worth the investment for us. Maybe it is not a speed
> daemon but to be honest the licensing costs of an SMP aware RDBMS is
> outside our budget. When postgresql start
Hello,
I am doing some test with differents values for the parameter maintenance_work_mem in order to
ameliorate the time for the creation of index and and the use of vacuum and analyse.
I read in the doc that this parameter is just for create index, vacuum and analyse and foreign key .
But when i
On fim, 2006-04-06 at 12:35 +1000, Brian Herlihy wrote:
> I have a problem with the choice of index made by the query planner.
>
> My table looks like this:
>
> CREATE TABLE t
> (
> p1 varchar not null,
> p2 varchar not null,
> p3 varchar not null,
> i1 integer,
> i2 integer,
> i3 in
Hi,
I have a problem with the choice of index made by the query planner.
My table looks like this:
CREATE TABLE t
(
p1 varchar not null,
p2 varchar not null,
p3 varchar not null,
i1 integer,
i2 integer,
i3 integer,
i4 integer,
i5 integer,
d1 date,
d2 date,
d3 date,
PRIMAR
Miguel wrote:
Excuse me for this off topic, but i notice that you are very excited
about the sun's hardware, what os do you install on them , slowlaris?,
has that os improved in some espectacular way that i should take a look
again?, i used it until solaris 9 and the performance was horrible
Chris Mair wrote:
Ok, so I did a few runs for each of the sync methods, keeping all the
rest constant and got this:
open_datasync 0.7
fdatasync 4.6
fsync 4.5
fsync_writethrough not supported
open_sync 0.6
in arbitrary units - higher is faster.
Quite impress
Mark Kirkwood wrote:
The newer Sun Opteron systems look nice too, but unless you're using
external storage, their little 2.5" hard drives may not be ideal.
Yes - but they end-of-lifed the V20z and V40z!
That's quite disappointing to hear -- our V40z isn't even six months
old! We're not a
28 matches
Mail list logo
