Re: SELECT's take a long time compared to other DBMS

I reset the shared_buffers to 1000 from 128, but it made no difference.

""scott.marlowe"" <scott(dot)marlowe(at)ihs(dot)com> wrote in message
news:Pine(dot)LNX(dot)4(dot)33(dot)0309041625300(dot)28714-100000(at)css120(dot)ihs(dot)com(dot)(dot)(dot)
> On Wed, 3 Sep 2003, Relaxin wrote:
>
> > I have a table with 102,384 records in it, each record is 934 bytes.
> >
> > Using the follow select statement:
> > SELECT * from <table>
> >
> > PG Info: version 7.3.4 under cygwin on Windows 2000
> > ODBC: version 7.3.100
> >
> > Machine: 500 Mhz/ 512MB RAM / IDE HDD
> >
> >
> > Under PG: Data is returned in 26 secs!!
> > Under SQL Server: Data is returned in 5 secs.
> > Under SQLBase: Data is returned in 6 secs.
> > Under SAPDB: Data is returned in 7 secs.
>
> This is typical of postgresql under cygwin, it's much faster under a Unix
> OS like Linux or BSD. That said, you CAN do some things to help speed it
> up, the biggest being tuning the shared_buffers to be something large
> enough to hold a fair bit of data. Set the shared_buffers to 1000,
> restart, and see if things get better.
>
> Running Postgresql in a unix emulation layer is guaranteed to make it
> slow. If you've got a spare P100 with 128 Meg of RAM you can throw redhat
> 9 or FreeBSD 4.7 on and run Postgresql on, it will likely outrun your
> 500MHZ cygwin box, and might even keep up with the other databases on that
> machine as well.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>