Unix Technical Forum

Re: firebird X postgresql 8.1.2 windows, performance comparison

This is a discussion on Re: firebird X postgresql 8.1.2 windows, performance comparison within the Pgsql Performance forums, part of the PostgreSQL category; --> Hello, Many thanks for the valuable suggestions and insights. The defaults enable_bitmapscan and enable_seqscan were altered by my friend. ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 08:14 AM
Andre Felipe Machado
 
Posts: n/a
Default Re: firebird X postgresql 8.1.2 windows, performance comparison

Hello,
Many thanks for the valuable suggestions and insights.
The defaults enable_bitmapscan and enable_seqscan were altered by my
friend. He already re enabled them (maybe even while I was trying some
of the queries).
The machine is a P4 3.2GHz, 1 GBram, sata hd, windows 2000. I did not
used pg on win before to have any advice to my friend.
The previously attached file contains SOME relevant info from the psql
session, in order to not clutter file.
When some server parameter was modified (at least by me) and server
restarted, a new sholl parameter was issued to show the new value.
Firebird is running at the same machine.
As you can see by the session log, indexes were created on the columns
used and tables was first clustered on the indexes actually used by the
query.
The subsequent cluster commands only recluster on the same indexes
previously clustered.
shared_buffers was increased from 1000 to 16384 pages
effective_cache_size was increased from 1000 to 65535 pages and at the
final steps REDUCED to 8192 pages
work_mem was increased from 1024 first to 16384 KB and then to 65535
KB.
The first 2 parameters reduced time 18%.
work_mem reduced time almost 66%.
But work_mem easily can exhaust ram with many users connected, as each
connection query will use this amount of memory (if I can remember).
How much it can grow at this 1 gbram win machine?
Some of the docs I already read suggested that indexes should be
entirely contained in ram. How to dimension the parameters?
Other docs adviced that some memory parameters could actually degrade
performance if too big. There are peak points at the performance curve
by adjusting mem parameters.
I hope tomorrow execute explain with the bitmapscan and seqscan enabled.
bitmapscans are almost always faster?

The data, as far I know, are a sample real app data (hey, if and when in
production it will be even large?). They are almost true random as my
friend informed, and according to him, cluster should not really be of
benefit. It seems confirmed by the various explain analyze commands
before and after clustering.

Any suggestions? Do you see some obvious error on the steps at the
previous session log file?
It seems that Firebird windows can use adequately as much ram it finds
and postgresql windows can not. How dimension ram to the indexes? Only
by trial and error? I tried some suggested values found at some tuning
docs suitable to the available system ram.

Thanks
Andre Felipe





---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-19-2008, 08:15 AM
Carlos Henrique Reimer
 
Posts: n/a
Default Re: firebird X postgresql 8.1.2 windows, performance comparison

Andre,

Could not Postgresql file cache being killed by firebird activity?
Haven´t you tried decrease ramdom_page_cost to 3 or 2?

It would be better if only one person will make configuration changes,
otherwise it will be difficult to measure each configuration change impact.

Reimer



Andre Felipe Machado <andremachado@techforce.com.br> escreveu:
Hello,
Many thanks for the valuable suggestions and insights.
The defaults enable_bitmapscan and enable_seqscan were altered by my
friend. He already re enabled them (maybe even while I was trying some
of the queries).
The machine is a P4 3.2GHz, 1 GBram, sata hd, windows 2000. I did not
used pg on win before to have any advice to my friend.
The previously attached file contains SOME relevant info from the psql
session, in order to not clutter file.
When some server parameter was modified (at least by me) and server
restarted, a new sholl parameter was issued to show the new value.
Firebird is running at the same machine.
As you can see by the session log, indexes were created on the columns
used and tables was first clustered on the indexes actually used by the
query.
The subsequent cluster commands only recluster on the same indexes
previously clustered.
shared_buffers was increased from 1000 to 16384 pages
effective_cache_size was increased from 1000 to 65535 pages and at the
final steps REDUCED to 8192 pages
work_mem was increased from 1024 first to 16384 KB and then to 65535
KB.
The first 2 parameters reduced time 18%.
work_mem reduced time almost 66%.
But work_mem easily can exhaust ram with many users connected, as each
connection query will use this amount of memory (if I can remember).
How much it can grow at this 1 gbram win machine?
Some of the docs I already read suggested that indexes should be
entirely contained in ram. How to dimension the parameters?
Other docs adviced that some memory parameters could actually degrade
performance if too big. There are peak points at the performance curve
by adjusting mem parameters.
I hope tomorrow execute explain with the bitmapscan and seqscan enabled.
bitmapscans are almost always faster?

The data, as far I know, are a sample real app data (hey, if and when in
production it will be even large?). They are almost true random as my
friend informed, and according to him, cluster should not really be of
benefit. It seems confirmed by the various explain analyze commands
before and after clustering.

Any suggestions? Do you see some obvious error on the steps at the
previous session log file?
It seems that Firebird windows can use adequately as much ram it finds
and postgresql windows can not. How dimension ram to the indexes? Only
by trial and error? I tried some suggested values found at some tuning
docs suitable to the available system ram.

Thanks
Andre Felipe





---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq



---------------------------------
Yahoo! Acesso Grátis
Internet rápida e grátis. Instale o discador agora!
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-19-2008, 08:15 AM
PFC
 
Posts: n/a
Default Re: firebird X postgresql 8.1.2 windows, performance comparison



> I hope tomorrow execute explain with the bitmapscan and seqscan enabled.
> bitmapscans are almost always faster?


Like all the rest, they're just a tool, which works great when used in
its intended purpose :

- Fetching just a few percent of the rows from a table is better served
by an index scan
- Fetching a lot of rows (>30-50%) from a table is better served by a seq
scan
- Bitmap scan comes in between and it's a very welcome addition.

Also Bitmap scan will save your life if you have complex searches, like
if you run a dating site and have an index on blondes and an index on boob
size, because it can use several indexes in complex AND/OR queries.

Common wisdom says simpler databases can be faster than postgres on
simple queries.

Reality check with pg 8.1 driven by PHP :

- SELECT 1
mysql 5 ~ 42 us
postgres ~ 70 us

- SELECT * FROM users WHERE id=1
mysql 5 ~ 180 us
postgres ~ 160 us

Of course people doing stupid things, like using the database to keep a
hit counter on their website which is updated on every hit, will say that
postgres is slow.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-19-2008, 08:15 AM
David Brown
 
Posts: n/a
Default Re: firebird X postgresql 8.1.2 windows, performance comparison

Andre Felipe Machado wrote:

>It seems that Firebird windows can use adequately as much ram it finds
>and postgresql windows can not.
>
>

PostgreSQL relies on the OS cache to utilize RAM. Make sure that most of
the RAM is 'available' so Windows can do its thing.

effective_cache_size should be set correspondingly high - at least 65535.

shared_buffers should be as low as you can get away with (allowing for
multiple users). 16384 is 12.5% of your RAM and far too high.

AFAIK, PostgreSQL still doesn't differentiate between index blocks and
data blocks.

>work_mem reduced time almost 66%.
>But work_mem easily can exhaust ram with many users connected, as each
>connection query will use this amount of memory (if I can remember).
>How much it can grow at this 1 gbram win machine?
>
>


work_mem has to be just big enough to allow hash joins to operate
efficiently. This varies from query to query and can be set in your code
accordingly. However, the 1024 default is just too low for most
applications and you'll probably find even 4096 is a huge improvement.
You need to find the minimum that delivers acceptable performance in
most queries and boost it for selected queries as required.

BTW, which version of Firebird is this?

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 04:40 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com