Dear Kevin,
Thanks for a very helpful reply.
Kevin Grittner wrote:
Richard Neill wrote:
Am I wrong in thinking that ORDER BY is always applied after the
main query is run?
Yes, you are wrong to think that. It compares the costs of various
plans, and when it has an index with the high or
Scott Carey wrote:
3ware 95xx and 96xx had performance somewhere between PERC 5 (horrid) and
PERC 6 (mediocre) when I tested them with large SATA drives with RAID 10.
Haven't tried raid 6 or 5. Haven't tried the "SA" model that supports SAS
The only models I've tested and recommended lately are
Scott Carey wrote:
> On 11/24/09 11:13 AM, "Scott Marlowe" wrote:
>
>
>
>> They get good reviews as well. Both manufacturers have their "star"
>> performers, and their "utility" or work group class controllers. For
>> what you're doing the areca 12xx or 3ware 95xx series should do fine.
>>
On 11/24/09 11:13 AM, "Scott Marlowe" wrote:
>
> They get good reviews as well. Both manufacturers have their "star"
> performers, and their "utility" or work group class controllers. For
> what you're doing the areca 12xx or 3ware 95xx series should do fine.
>
-1 to 3ware's SATA solutions
Richard Neill wrote:
> Am I wrong in thinking that ORDER BY is always applied after the
> main query is run?
Yes, you are wrong to think that. It compares the costs of various
plans, and when it has an index with the high order portion matching
your ORDER BY clause, it may think that it can s
Jean-Michel Pouré wrote:
Le mardi 01 décembre 2009 à 18:52 +, Richard Neill a écrit :
Is this normal? Have I hit a bug?
PostgreSQL query analyzer needs to run a couple of times before it can
rewrite and optimize the query. Make sure demand_id, id and join IDs
carry indexes.
I did, and
Le mardi 01 décembre 2009 à 18:52 +, Richard Neill a écrit :
> Is this normal? Have I hit a bug?
PostgreSQL query analyzer needs to run a couple of times before it can
rewrite and optimize the query. Make sure demand_id, id and join IDs
carry indexes.
Run EXPLAIN ANALYSE your_query to underst
Richard Neill wrote:
> I'd expect the ORDER BY to be the last thing that runs
> Nested Loop Left Join (cost=0.00..727737158.77
> rows=806903677108 width=195) (actual time=31739.052..32862.322
> rows=15 loops=1)
It probably would if it knew there were going to be 15 rows to sort.
It is est
Dear All,
I don't know if this is a stupid question, or not, but I can't
understand the following.
I have a pretty simple query, which runs in about 7ms
SELECT * FROM h.inventory WHERE demand_id =289276563;
The result of this is a 15 row x 17 column table. However, I want this
to be sort
> -Mensaje original-
> De: Waldomiro
>
> I´m using PostgreSQL 8.1,
Sorry, log_checkpoints isn't supported till 8.3
> and my settings are:
>
> checkpoint_segments=50
> checkpoint_timeout=300
> checkpoint_warning=30
> commit_delay=0
> commit_siblings=5
> archive_command= cp -i %p/BACK
I´m using PostgreSQL 8.1, and my settings are:
checkpoint_segments=50
checkpoint_timeout=300
checkpoint_warning=30
commit_delay=0
commit_siblings=5
archive_command= cp -i %p/BACKUP/LOGS/%f
autovacuum=off
bgwriter_all_maxpages=5
bgwriter_all_percent=0.333
bgwriter_delay=200
bgwriter_lru_maxpage
I´m using PostgreSQL 8.1. There is a way to see that?
Waldomiro
Greg Smith escreveu:
Waldomiro wrote:
Is It possible the checkpoint is doing that? Or the archiving? How
can I see?
If you're using PostgreSQL 8.3 or later, you can turn on
log_checkpoints and you'll get a note when each checkpoi
12 matches
Mail list logo
