bb.donnay-software.com

I used the DBFUPSIZE tool to import some databases into a PostGreSql table.

The data imported ok, but I have no indexes.

I can connect to the database with DacSession() and open the table with USE but I get none of my indexes. What am I doing wrong?

Suddenly it is working.
I don't know why.

I imported several large ADS databases and it really is slow compared to ADS.

I am not convinced that moving from ADS to PostGres is viable.

rdonnay wrote:I imported several large ADS databases and it really is slow compared to ADS.
I am not convinced that moving from ADS to PostGres is viable.

it is the Overhead of pgDBE ... using PostgreSQL DLL "native" is much quicker.

using PostgreSQL DLL "native" is much quicker

We have thousands of lines of ISAM code. We would need to use PGDBE to migrate this app.
I think we will just stay with ADS. It works flawlessly.

rdonnay wrote:

using PostgreSQL DLL "native" is much quicker

We have thousands of lines of ISAM code. We would need to use PGDBE to migrate this app.

just want to say PostgreSQL itself in not slow.
If we would get DBE API Description from Alaska ( like Phil Ide / Sander Elias ***) we can write own ISAM Wrapper.

***
Sander Elias
26. Juli 2012 ( Start 21. Juli 2012 )
xfree.public
Re: PostgreSQL LIMIT OFFSET on big Table

p.s. if Alaska switch to PostgreSQL v9.x API a lot of ISAM "Problem" can be solved using new SQL Command like RowNumber() which is not available in v8.x

we can write own ISAM Wrapper.

I don't think this will work.

Advantage started as an ISAM client/server. This means that the SQL stuff is built on top of the ISAM engine.
When ISAM support is needed, it is very fast.

PostGres started as a SQL client/server. ISAM would have to be "emulated" using SQL commands, hidden fields and tables.
I believe this is why it is so slow with Xbase++. If I were to use PostGres, I would not use it via the PGDBE. This may be fine for small databases, but we are using tables with millions of records.

Some years ago (shortly after WW II ), Steffen mentioned, using PGDBE with ISAM emulation should be faster than native DBEs (DBFNTX/CDX) from 3 workstations on in a heavy utilized network. But he wasn't comparing to ADS and he wasn't talking about very large datasets. I guess, retrieving a single record is done by a select statement anyway, maybe a little optimized, but at least, a single ISAM-emulating record must be a cursor. This can't be faster compared to ADS. SQL-servers don't deal single records. This is against the paradigm.

Hi All,

I took an introductory course for PostgreSQL database administration. Unfortunately PostgreSQL does not come tuned optimally upon setup. It is however pretty simple to change and optimize a few settings for your particular system. I would recommend entering your system specs into this calculator.

http://pgtune.leopard.in.ua/

Then find your postgresql.conf file in C:\Program Files (x86)\PostgreSQL\8.3\data and update those values (certain values may be missing depending on PostgreSQL version).

You will have to remove the # in front to activate the setting, also a postgres dbe restart or system restart is required any time certain postgresql.conf values are changed.

You can find a brief overview of what these settings do as well as a more advanced performance tuning article. I would imagine for the majority of our applications just the few basic setting changes should suffice.

https://wiki.postgresql.org/wiki/Tuning ... SQL_Server
http://www.revsys.com/writings/postgres ... mance.html

I would imagine that the Xbase++ PGDBE does take up some overhead, however if we can offload as much data processing to the system RAM by increasing certain value limits, this may have some performance benefit. We all know RAM is 10-20 faster than magnetic Hard Disk Drives, SSD being the next best thing.

We will be doing our own testing here shortly by using the SQL command EXPLAIN ANALYZE, it should be possible to quantify the changes and see if they have any affect. I would be interested to hear from devs if changing these settings improves performance on Upsized ISAM tables into PostgreSQL. Especially with larger data sets.

Regards,
Gerrit

Gerrit -

Thanks.
I will experiment with the .Conf file.

Roger