PostgreSQL performance - CAPIPreparedStatement

The official tester's forum for ZeosLib 7.1. Ask for help, post proposals or solutions.
Post Reply
rayanAyar
Fresh Boarder
Fresh Boarder
Posts: 13
Joined: 02.07.2010, 04:26

PostgreSQL performance - CAPIPreparedStatement

Post by rayanAyar »

I migrated from Zeos 7.0.3 to 7.1.2. And PostgreSQL performance highly reduced in some parts of code. One query which executes several times per minute:
on 7.0.3 takes 150 milliseconds
on 7.1.2 takes 1000 milliseconds

Еxamining and tracing code, I found some dirty solution:
file "src/dbc/ZDbcPostgreSql.pas", function TZPostgreSQLConnection.CreatePreparedStatement:

Code: Select all

      if GetServerMajorVersion >= 8 then
        //Original code: Result := TZPostgreSQLCAPIPreparedStatement.Create(GetPlainDriver, Self, SQL, Info)
        Result := TZPostgreSQLClassicPreparedStatement.Create(GetPlainDriver, Self, SQL, Info)
      else
        Result := TZPostgreSQLClassicPreparedStatement.Create(GetPlainDriver, Self, SQL, Info);
CAPIPreparedStatement works very slow in my case, so I changed it to ClassicPreparedStatement.

In this regard, I have two questions:
1. Is this a bug?
2. If this is not a bug - can I perform such patch as described above? Will this affect other functions or stability?
miab3
Zeos Test Team
Zeos Test Team
Posts: 1310
Joined: 11.05.2012, 12:32
Location: Poland

Re: PostgreSQL performance - CAPIPreparedStatement

Post by miab3 »

@rayanAyar,

Could you give an example?

Michal
User avatar
EgonHugeist
Zeos Project Manager
Zeos Project Manager
Posts: 1936
Joined: 31.03.2011, 22:38

Re: PostgreSQL performance - CAPIPreparedStatement

Post by EgonHugeist »

There is one Main-difference on 7.1 between the two statments:

the CAPI one always !prepares! the request, while the Classic stmt just do it if ParamCount > 0 or ExecutionCount > 2.

So you difference is because of the Prepare compile on Postgres-side. BUT a second or more execution should be loads faster than. Again just the first call should be slow. Reopening same query performes loads (hope the slow PG is really able to do that) faster than.

Also is this an design thing on your application. Try to keep one query request alive until you close your app. Than the prepared stmts do really make sence. Also working with parameters is prefered....

So could you test reopening your select with min. 5 times?

ps. Prepared stmts do have advantages but preparing the execution plans first does take time. IMO the CAPI type should be the fastest becouse PG doesn't need any string parsing if prepared....
Best regards, Michael

You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/

Image
rayanAyar
Fresh Boarder
Fresh Boarder
Posts: 13
Joined: 02.07.2010, 04:26

Re: PostgreSQL performance - CAPIPreparedStatement

Post by rayanAyar »

EgonHugeist wrote: Again just the first call should be slow. Reopening same query performes loads (hope the slow PG is really able to do that) faster than.
Works slow every time.
EgonHugeist wrote: Try to keep one query request alive until you close your app. Than the prepared stmts do really make sence.
Practically all querries that I use - created once and reused until close app.
EgonHugeist wrote: Also working with parameters is prefered....
Almost all querries that I use - working with parameters. And query about I told in first message (which became slower in 7.1.2) - too.
EgonHugeist wrote: Prepared stmts do have advantages but preparing the execution plans first does take time.
Thats why I always try to use prepared statements. First call is slow but next calls are very fast. It works well in Zeos 7.0.3. But does not work for me in Zeos 7.1.2 - all calls (second, third, ... tenth) takes the same time. And this time is big. :(
User avatar
mdaems
Zeos Project Manager
Zeos Project Manager
Posts: 2766
Joined: 20.09.2005, 15:28
Location: Brussels, Belgium
Contact:

Re: PostgreSQL performance - CAPIPreparedStatement

Post by mdaems »

This is strange behavior indeed. did you try adding a zsqlmonitor to check if only one prepare is executed? Maybe the statement is not preparable for some reason.
Image
Post Reply