I have two tables in the database which are used almost every time
someone makes use of the webpages themselves. The first, is some sort
of database side parameter list which stores parameters from session to
session. While the other, is a table that handles the posting activity
of all the rooms
On 17 Jul 2003 at 10:41, Nick Fankhauser wrote:
> I'm using ext2. For now, I'll leave this and the OS version alone. If I
I appreciate your approach but it almost proven that ext2 is not the best and
fastest out there.
IMO, you can safely change that to reiserfs or XFS. Or course, testing is
al
On Fri, 18 Jul 2003, Fabian Kreitner wrote:
> Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
Doesn't sound very good and it will most likely make other queries slower.
You could always turn off sequential scan before that query and turn it on
after.
> Anything I need
Hi all,
Adjusting the cpu_tuple_cost to 0.042 got the planner to choose the index.
Anything I need to consider when raising it to such "high" values?
Thanks for the help,
Fabian
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
At 20:12 17.07.2003, Tom Lane wrote:
Fabian Kreitner <[EMAIL PROTECTED]> writes:
> That is what I read too and is why Im confused that the index is indeed
> executing faster. Can this be a problem with the hardware and/or postgress
> installation?
I think the actual issue here is that you are execu
On Thu, 17 Jul 2003 16:20:42 +0100
Adam Witney <[EMAIL PROTECTED]> said something like:
>
> Actually I am going through the same questions myself at the
> moment I would like to have a 2 disk RAID1 and a 4 disk RAID5, so
> need at least 6 disks
>
> Anybody have any suggestions or experie
Folks:
On my projects, I haven't found PostgreSQL's implementation of clustered
indexes to be particularly useful ... gains of only a few percent in query
efficiency in exchange for a substantial management task. Obviously, not
everyone has had the same experience, or we wouldn't still have th
>Adam Witney wrote:
>> Actually I am going through the same questions myself at the
>moment I
>> would like to have a 2 disk RAID1 and a 4 disk RAID5, so
>need at least 6
>> disks
>>
>> Anybody have any suggestions or experience with other
>hardware manufacturers
>> for this size of set
Tom Lane wrote:
Bill Moran <[EMAIL PROTECTED]> writes:
Specifically, I'm wondering if I should do
the ANALYZE before or after I recreate the indexes, or whether it matters.
At the moment it does not matter --- ANALYZE computes statistics for
each column of a table regardless of what indexes exis
On Thu, Jul 17, 2003 at 07:57:53AM -0700, Joe Conway wrote:
>
> As I said, I've never personally found it necessary to move WAL off to a
> different physical drive. What do you think is the best configuration
On our Solaris test boxes (where, alas, we do not have the luxury of
1/2 TB external R
Bill Moran <[EMAIL PROTECTED]> writes:
> Specifically, I'm wondering if I should do
> the ANALYZE before or after I recreate the indexes, or whether it matters.
At the moment it does not matter --- ANALYZE computes statistics for
each column of a table regardless of what indexes exist.
There has
Fabian Kreitner <[EMAIL PROTECTED]> writes:
> That is what I read too and is why Im confused that the index is indeed
> executing faster. Can this be a problem with the hardware and/or postgress
> installation?
I think the actual issue here is that you are executing the EXISTS
subplan over and o
Paul Thomas <[EMAIL PROTECTED]> writes:
> 2) enable_seqscan = false
>> Seq Scan on notiz_objekt a (cost=1.00..100111719.36 rows=15561
>> width=12) (actual time=0.25..535.75 rows=31122 loops=1)
> I've just noticed this. Something is not right here. Look at the crazy
> cost estimation for
On Thu, 2003-07-17 at 08:20, Adam Witney wrote:
> Anybody have any suggestions or experience with other hardware manufacturers
> for this size of setup? (2U rack, up to 6 disks, 2 processors, ~2GB RAM, if
> possible)
>
> Thanks
>
> adam
Check out http://www.amaxit.com It is all white box stuf
Sorry for the redundant duplication of the repetition.
I should have read the follow-up messages.
Joe Conway wrote:
>
> Jean-Luc Lachance wrote:
> > I am currious. How can you have RAID 1+0 with only 2 drives?
> > If you are thinking about partitioning the drives, wont this defeate the
> > purpo
Nick Fankhauser wrote:
Thanks for the correction- it sounds like this is one where usage
can't be precisely controlled in a dynamic user environment & I just
need to get a feel for what works under a load that approximates my
production system.
I think the most important point here is that if you s
Adam Witney wrote:
Actually I am going through the same questions myself at the moment I
would like to have a 2 disk RAID1 and a 4 disk RAID5, so need at least 6
disks
Anybody have any suggestions or experience with other hardware manufacturers
for this size of setup? (2U rack, up to 6 disk
Jean-Luc Lachance wrote:
I am currious. How can you have RAID 1+0 with only 2 drives?
If you are thinking about partitioning the drives, wont this defeate the
purpose?
Yeah -- Hannu already pointed out that my mind was fuzzy when I made
that statement :-(. See subsequent posts.
Joe
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A Dimecres 16 Juliol 2003 16:38, Tom Lane va escriure:
> Albert Cervera Areny <[EMAIL PROTECTED]> writes:
> > I have a performance problem using postgresql when the connection is
> > made via ODBC with a windows machine using the latests ODBC drivers
On Thursday 17 Jul 2003 3:45 pm, Bill Moran wrote:
> Hello all,
>
> I'm putting together a database that has me wondering about the interaction
> of ANALYZE with indices. I guess the basic question is: are indices
> affected by the results of ANALYZE.
>
> The particular application I've got is doi
> Wrong, actually. Sort memory is allocated *per sort*, not per
connnection or
> per query. So a single complex query could easily use 4xsort_mem if it
has
> several merge joins ...
Thanks for the correction- it sounds like this is one where usage can't be
precisely controlled in a dynamic us
I am currious. How can you have RAID 1+0 with only 2 drives?
If you are thinking about partitioning the drives, wont this defeate the
purpose?
JLL
Joe Conway wrote:
>
> [...]
> 2 drives, RAID 1+0: WAL
> 2 drives, RAID 1+0: data
> [...]
---(end of broadcast)--
Nick,
> I'll try that approach while testing. Is it the case that the sort memory
> is allocated for each connection and becomes unavailable to other processes
> while the connection exists? If so, since I'm using a connection pool, I
> should be able to control total usage precisely. Without a co
Shridhar-
I appreciate your thoughts- I'll be running some before & after tests on
this using one of our development/hot-swap boxes, so I'll report the results
back to the list.
A few more thoughts/questions:
> 1. 30 users does not seem to be much of a oevrhead. If possible
> try doing away with
On 17/7/03 4:09 pm, "Joe Conway" <[EMAIL PROTECTED]> wrote:
> Adam Witney wrote:
>> I think the issue from the original posters point of view is that the Dell
>> PE2650 can only hold a maximum of 5 internal drives
>>
>
> True enough, but maybe that's a reason to be looking at other
> alternative
Adam Witney wrote:
I think the issue from the original posters point of view is that the Dell
PE2650 can only hold a maximum of 5 internal drives
True enough, but maybe that's a reason to be looking at other
alternatives. I think he said the hardware hasn't been bought yet.
Joe
---
> As I said, I've never personally found it necessary to move WAL off to a
> different physical drive. What do you think is the best configuration
> given the constraint of 5 drives? 1 drive for OS, and 4 for RAID 1+0 for
> data-plus-WAL? I guess the ideal would be to find enough money for that
>
Hannu Krosing wrote:
How do you do RAID 1+0 with just two drives ?
Hmm, good point -- I must have been tired last night ;-). With two
drives you can do mirroring or striping, but not both.
Usually I've seen a pair of mirrored drives for the OS, and a RAID 1+0
array for data. But that requires 6
Hello all,
I'm putting together a database that has me wondering about the interaction of ANALYZE
with indices. I guess the basic question is: are indices affected by the results of
ANALYZE.
The particular application I've got is doing a batch insert of lots of records. For
performance, I'm drop
On 17/07/2003 13:50 Fabian Kreitner wrote:
[snip]
Im afraid, no.
Database has been stopped / started right before this.
[snip]
1) enable_seqscan = true
Seq Scan on notiz_objekt a (cost=0.00..56125.80 rows=15561 width=12)
(actual time=0.28..2298.71 rows=31122 loops=1)
[snip]
2) enable_seqscan = fa
I've seen similar behavior in my own queries. I found that reducing
random_page_cost from the default of 4 down to 2 caused the query to
choose the index, and resulted in an order of magnitude improvement on
some queries.
On Thu, 2003-07-17 at 05:50, Fabian Kreitner wrote:
> At 14:34 17.07.2003,
On 17 Jul 2003 at 14:50, Fabian Kreitner wrote:
> At 14:34 17.07.2003, you wrote:
> >I expect you will find that the third query is also a lot faster that the
> >first query.
>
> Im afraid, no.
> Database has been stopped / started right before this.
>
> perg_1097=# set enable_seqscan to true;
At 14:34 17.07.2003, you wrote:
On 17/07/2003 12:13 Fabian Kreitner wrote:
That is what I read too and is why Im confused that the index is indeed
executing faster. Can this be a problem with the hardware and/or
postgress installation?
It's more likely that the OS has most of the data cached a
On 17/07/2003 12:13 Fabian Kreitner wrote:
That is what I read too and is why Im confused that the index is indeed
executing faster. Can this be a problem with the hardware and/or
postgress installation?
It's more likely that the OS has most of the data cached after the first
query and so does
On 17 Jul 2003 at 13:12, Fabian Kreitner wrote:
> At 11:17 17.07.2003, Shridhar Daithankar wrote:
> >How about
> >
> > where ma_id = 2001::integer
> >and ma_pid = 1097::integer
> >
> >in above query?
>
> I dont really understand in what way this will help the planner but ill try.
That is
At 11:17 17.07.2003, Shridhar Daithankar wrote:
On 17 Jul 2003 at 11:01, Fabian Kreitner wrote:
> psql (PostgreSQL) 7.2.2
>
> perg_1097=# VACUUM ANALYZE ;
> VACUUM
> perg_1097=# EXPLAIN ANALYZEselect notiz_id, obj_id, obj_typ
> perg_1097-# fromnotiz_objekt a
> perg_1097-# where not
At 12:12 17.07.2003, you wrote:
On 17/07/2003 10:01 Fabian Kreitner wrote:
Hi Fabian,
When you are doing these kinds of tests, you need to be aware that the
kernel may have most of your data cached after the first query and this
may be why the second query appears to run faster.
I thought of t
On 2003-07-16 19:57:22 -0700, Balazs Wellisch wrote:
> We're now stuck on the question of what type of RAID configuration to use
> for this server. RAID 5 offers the best fault tolerance but doesn't perform
> all that well. RAID 10 offers much better performance, but no hot swap. Or
> should we not
On 17/07/2003 10:01 Fabian Kreitner wrote:
Hi Fabian,
When you are doing these kinds of tests, you need to be aware that the
kernel may have most of your data cached after the first query and this
may be why the second query appears to run faster.
Also don't be worried if the planner chooses a
On 17 Jul 2003 at 11:01, Fabian Kreitner wrote:
> psql (PostgreSQL) 7.2.2
>
> perg_1097=# VACUUM ANALYZE ;
> VACUUM
> perg_1097=# EXPLAIN ANALYZEselect notiz_id, obj_id, obj_typ
> perg_1097-# fromnotiz_objekt a
> perg_1097-# where not exists
> perg_1097-# (
> perg_1097(#
Hi all,
Im currently taking my first steps with db optimizations and am wondering
whats happening here and if/how i can help pg choose the better plan.
Thanks,
Fabian
>>>
psql (PostgreSQL) 7.2.2
perg_1097=# VACUUM ANALYZE ;
VACUUM
perg_1097=# EXPLAIN ANALYZEselect notiz_id, obj_id, obj_
Joe Conway kirjutas N, 17.07.2003 kell 07:52:
> To an extent it depends on how big the drives are and how large you
> expect the database to get. For maximal performance you want RAID 1+0
> for data and WAL; and you want OS, data, and WAL each on their own
> drives. So with 5 drives one possible
42 matches
Mail list logo
