Re: Performance analysis of server-parsed PreparedStatements

From: Barry Lind <blind(at)xythos(dot)com>
To: James Robinson <jlrobins(at)socialserve(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Performance analysis of server-parsed PreparedStatements
Date: 2004-04-16 21:47:37
Message-ID: 40805479.90008@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

James,

Thanks for spending the time to do these benchmarks. It is always
important to have real numbers when making decisions about how to
improve things.

Your numbers indicate that the 'prepare on passing threshold' is
probably the right way to go, because anything else would not always be
a win. And certainly anything more aggressive is likely to hurt
performance.

Of course when we get to a V3 protocol implementation then server
prepared statements will probably always be a win, but as long as the V2
protocol is still used your benchmarking provides useful information on
a path forward.

--Barry

James Robinson wrote:
> I began doing various benchmarks with JBoss 3.2.3 maintaining a pool of
> prepared statements on postgres 7.4.2, with a few hacks to the JDBC
> driver to ultimately get performance higher than without any pooled
> prepared statements or server-side preparation. Things learned from this
> endeavor should be of users of JBoss + PG, the JDBC driver implementors,
> and backend coders.
>
> The benchmarking was done with a subset of our EJB app's regression test
> suite.
>
> All JDBC hacks were done in AbstractJdbc1Statement.
>
> Hacks:
>
> 1) Our primary keys are almost exclusively int8s. Tom's
> cross-integral index operator fix for 7.5 would reduce the count of
> local hacks in the JDBC driver to pull this off. Those hacks involve
> explicitly tacking on '::INT8' to the value string in setLong(int, long)
> and setObject(int, Object, int, int)'s "CASE Types.BIGINT" clause.
> Without this you get the horse-beaten-to-death issue of sequential scan
> instead of index scan for non-server prepared queries problem.
>
> 2) JBoss pays attention to the # rows updated count from update /
> insert statements. Server prepared queries currently don't return the
> updated row count. The asked-for protocol update would allow for this
> value to be returned through JDBC regardless of prepared or not. So,
> only server prepare if it is a select statement.
>
> 3) JBoss can (and will, depending on configuration settings +
> contents of various runtime caches) issue rather stupidly large queries
> along the lines of "select * from table where (id = 1) or (id = 2) or
> ... (id = 750). Yep -- 752 node OR grouping. I chose to skip auto-server
> preparation if the query had more than N parameters, with N currently
> set to 30, since those would most likely never get reused again.
>
> 4) When server preparing a query, initialize a counter to count how
> many times this prepared statement was reused. So, executing it twice
> would yield a reuse count of 1. Print out this count + the SQL query
> string when the prepared statement is closed.
>
> Hacks #2 and #3 amounted to:
>
> /** threshold for using a server-side prepared query -- never
> prepare if more than this. */
> private final static int MAX_ARGS_TO_PREPARE = 30;
>
> public AbstractJdbc1Statement (BaseConnection connection, String
> p_sql) throws SQLException
> {
> this.connection = connection;
> parseSqlStmt(p_sql); // this allows Callable stmt to override
> if(isSingleSelect() && m_bindTypes.length < MAX_ARGS_TO_PREPARE)
> setUseServerPrepare(true);
> }
>
> I performed 3 sets of tests:
>
> 1) No server-preparation at all, no JBoss statement pooling (vanilla
> setup).
> 2) Server preparation for single-select statements, but no JBoss
> statement pooling.
> 3) Server preparation for single-select statements, JBoss pool of
> prepared statements set to 500.
>
> Each test run started with the same initial database state, including
> all vacuumed and analyzed. JBoss restarted every time to have it start
> with an empty EJB cache.
>
> Here are the results (minutes:seconds), with high and low run removed:
>
> Suite #1 (vanilla):
> 4:39.57
> 4:41.21
> 4:47.09
>
> Suite #2 (server prepared but not jboss cached):
> 4:38.63
> 5:00.09
> 5:30.89
>
> Suite #3 (server prepared, jboss cached):
> 3:53.79
> 3:56.74
> 3:55.50
>
> Analysis:
>
> Suite #2 performed the worst. I expect it to be due to the overhead
> of closing the prepared statement right after using it (most likely
> exactly once), requiring the close operation to issue an additional
> jboss -> postgres round trip cost for the DEALLOCATE command. The
> standard deviation between runs is also much higher -- perhaps
> additional java GC overhead or the additional context switch jitters. It
> is extremely unlikely for the jboss 3.2 series CMP layer to reuse a
> preparedstatement within a single method. This can be easily seen from
> the prepared statement names, each statement being named via an
> auto-incrementing counter in the JDBC driver. A suite #2 run ends up
> preparing + closing 11,848 single select statements, and of those,
> absolutely none of them were reused within the lifetime of the prepared
> statement.
>
> Suite #3 performed the best, ~30 seconds better than 'vanilla'.
> Attached are the reuse counters (along with the query that was reused),
> sorted numerically by the reuse count. Many of the statements get reused
> quite a bit, but they are relatively simple -- we don't do many joins
> with more than 4 tables anywhere in our application, and looks like none
> more than 2 or 3 tables in this test suite. So, combined with pooled
> prepared statements, prepared statements *might* be a winner for an EJB
> application. JBoss issues many individual queries, but reducing them to
> a distinct set even across method calls brought them down by a factor of
> 20, indicating a high hit rate in the jboss prepared statement cache for
> this particular workload (for select statements, anyway).
>
> Given these results, I would recommend *not* turning on auto-server
> preparation in the JDBC driver for any sort of query, be they single
> select statements or updates, when the client -> backend protocol can
> support returning the proper row update count, since it can definitely
> impact performance of applications today.
>
> The 'prepare on passing threshold' patch would be great here, since
> it would have effectively made batch #2 equivalent to batch #1 (vanilla)
> -- no additional cost when PreparedStatements are not cached + reused.
> It would also enable performance just slightly worse than case #3 if the
> threshold were set to something like 3 or 4 when also using the JBoss
> statement cache, since the first 3 or so invocations would be
> non-prepared, then auto-switching to server-prepared when it really
> looked like this was a non-unique query (such as the 734-node OR queries).
>
> James
>
>
>
>
> ------------------------------------------------------------------------
>
> 12:00:51,798 INFO [STDOUT] PreparedStatement reuseCount: 1750, SELECT firstName, middleName, lastName, organizationName, version FROM contact WHERE (id=?)
> 12:00:51,790 INFO [STDOUT] PreparedStatement reuseCount: 1695, SELECT id, id, name, street, street2, city, state, zip, contact FROM address WHERE (contact=?)
> 12:00:51,795 INFO [STDOUT] PreparedStatement reuseCount: 1632, SELECT name, extension, type FROM organization WHERE (id=?)
> 12:00:51,619 INFO [STDOUT] PreparedStatement reuseCount: 1486, SELECT name, password, features, version, comment, pwd_storage_style, deleted, old_name, deleted_date, contact, organization FROM users WHERE (id=?)
> 12:00:51,615 INFO [STDOUT] PreparedStatement reuseCount: 1485, SELECT realtycompany.id, realtycompany.id, realtycompany.features, realtycompany.type, realtycompany.website, realtycompany.description, realtycompany.spanish, realtycompany.creditCheck, realtycompany.criminalCheck, realtycompany.fee, realtycompany.perAdult, realtycompany.negotiable, realtycompany.delete, realtycompany.deleteDate, realtycompany.allowed_idle_days, realtycompany.version, realtycompany.comment, realtycompany.organization, realtycompany.privateContact, realtycompany.defaultContact FROM realtycompany WHERE id=?
> 12:00:51,875 INFO [STDOUT] PreparedStatement reuseCount: 492, SELECT COUNT(*) FROM notificationlog WHERE id=?
> 12:00:51,864 INFO [STDOUT] PreparedStatement reuseCount: 395, SELECT t0_v.id, t0_v.id, t0_v.nextVersion, t0_v.name, t0_v.reasonToBe, t0_v.displayName, t0_v.prod_content_id FROM versionedcontent t0_v WHERE (t0_v.name = ?)
> 12:00:51,861 INFO [STDOUT] PreparedStatement reuseCount: 361, SELECT COUNT(*) FROM notification WHERE id=?
> 12:00:51,803 INFO [STDOUT] PreparedStatement reuseCount: 312, SELECT id, id, name, value, contact, areacode FROM phone WHERE (contact=?)
> 12:00:51,801 INFO [STDOUT] PreparedStatement reuseCount: 312, SELECT id, id, name, value, contact FROM email WHERE (contact=?)
> 12:00:51,855 INFO [STDOUT] PreparedStatement reuseCount: 199, SELECT DISTINCT t0_n.id, t0_n.id, t0_n.status, t0_n.companyType, t0_n.mechanism, t0_n.otherReasonString, t0_n.wasSuccessful, t0_n.whenDate, t0_n.toDo, t0_n.checkedOut, t0_n.done, t0_n.contactName, t0_n.contactInfo, t0_n.owner, t0_n.areacode, t0_n.user_id, t0_n.reason_id, t0_n.companyid FROM notification t0_n, versionedcontent t2_n_reason, organization t1_n_organization WHERE (t1_n_organization.id = ? AND t0_n.status = ? AND t0_n.mechanism = ? AND t2_n_reason.name = ? AND t0_n.reason_id=t2_n_reason.id AND t0_n.companyid=t1_n_organization.id)
> 12:00:51,852 INFO [STDOUT] PreparedStatement reuseCount: 195, SELECT DISTINCT t0_u.id, t0_u.id, t0_u.name, t0_u.password, t0_u.features, t0_u.version, t0_u.comment, t0_u.pwd_storage_style, t0_u.deleted, t0_u.old_name, t0_u.deleted_date, t0_u.contact, t0_u.organization FROM users t0_u, organization t1_u_organization WHERE (t1_u_organization.id = ? AND t0_u.organization=t1_u_organization.id)
> 12:00:51,774 INFO [STDOUT] PreparedStatement reuseCount: 171, SELECT COUNT(*) FROM phone WHERE id=?
> 12:00:51,777 INFO [STDOUT] PreparedStatement reuseCount: 132, SELECT t0_c.id, t0_c.id, t0_c.code, t0_c.nytdiff FROM areacode t0_c WHERE (t0_c.code = ?)
> 12:00:51,787 INFO [STDOUT] PreparedStatement reuseCount: 119, SELECT t0_ut.id, t0_ut.id, t0_ut.type, t0_ut.ticket, t0_ut.expdate, t0_ut.disabledUntil, t0_ut.user_id FROM userticket t0_ut, users t1_ut_user WHERE ((t1_ut_user.id=?) AND t0_ut.type = ? AND t0_ut.user_id=t1_ut_user.id)
> 12:00:51,793 INFO [STDOUT] PreparedStatement reuseCount: 118, SELECT id, id, name, password, features, version, comment, pwd_storage_style, deleted, old_name, deleted_date, contact, organization FROM users WHERE (organization=?)
> 12:00:51,771 INFO [STDOUT] PreparedStatement reuseCount: 99, SELECT COUNT(*) FROM email WHERE id=?
> 12:00:51,759 INFO [STDOUT] PreparedStatement reuseCount: 63, SELECT COUNT(*) FROM contact WHERE id=?
> 12:00:51,711 INFO [STDOUT] PreparedStatement reuseCount: 55, SELECT COUNT(*) FROM userticket WHERE id=?
> 12:00:51,769 INFO [STDOUT] PreparedStatement reuseCount: 31, SELECT COUNT(*) FROM userrole WHERE id=?
> 12:00:51,765 INFO [STDOUT] PreparedStatement reuseCount: 31, SELECT COUNT(*) FROM users WHERE id=?
> 12:00:51,762 INFO [STDOUT] PreparedStatement reuseCount: 31, SELECT t0_u.id, t0_u.id, t0_u.name, t0_u.password, t0_u.features, t0_u.version, t0_u.comment, t0_u.pwd_storage_style, t0_u.deleted, t0_u.old_name, t0_u.deleted_date, t0_u.contact, t0_u.organization FROM users t0_u WHERE (t0_u.name = ?)
> 12:00:51,872 INFO [STDOUT] PreparedStatement reuseCount: 23, SELECT DISTINCT t0_n.id, t0_n.id, t0_n.status, t0_n.companyType, t0_n.mechanism, t0_n.otherReasonString, t0_n.wasSuccessful, t0_n.whenDate, t0_n.toDo, t0_n.checkedOut, t0_n.done, t0_n.contactName, t0_n.contactInfo, t0_n.owner, t0_n.areacode, t0_n.user_id, t0_n.reason_id, t0_n.companyid FROM notification t0_n, organization t1_n_organization WHERE (t1_n_organization.id = ? AND t0_n.companyid=t1_n_organization.id)
> 12:00:51,755 INFO [STDOUT] PreparedStatement reuseCount: 19, SELECT COUNT(*) FROM address WHERE id=?
> 12:00:51,716 INFO [STDOUT] PreparedStatement reuseCount: 15, SELECT COUNT(*) FROM organization WHERE id=?
> 12:00:51,713 INFO [STDOUT] PreparedStatement reuseCount: 15, SELECT COUNT(*) FROM realtycompany WHERE id=?
> 12:00:51,867 INFO [STDOUT] PreparedStatement reuseCount: 13, SELECT DISTINCT rc.id, rc.id, rc.features, rc.type, rc.website, rc.description, rc.spanish, rc.creditCheck, rc.criminalCheck, rc.fee, rc.perAdult, rc.negotiable, rc.delete, rc.deleteDate, rc.allowed_idle_days, rc.version, rc.comment, rc.organization, rc.privateContact, rc.defaultContact FROM realtycompany rc , building b, unit u WHERE rc.delete = FALSE AND u.status = ? AND u.alwaysAvailable = FALSE AND u.availableDate < now() AND u.postDate < (now() - (rc.allowed_idle_days::text || ' days')::interval) AND u.building = b.id AND b.realtycompany = rc.id and rc.id not in (select rc.id from userlogin ul, users u, realtycompany rc where rc.id = u.organization and u.id = ul.user_id and ul.date > now() - (rc.allowed_idle_days::text || ' days')::interval) and rc.id not in (select rc.id from notification n, realtycompany rc, versionedcontent vc where n.companyid = rc.id and n.reason_id = vc.id and vc.name=? and (n.todo > (

now() - (rc.allowed_idle_days::text || ' days')::interval) or n.done >
(now() - (rc.allowed_idle_days::text || ' days')::interval)))
> 12:00:51,848 INFO [STDOUT] PreparedStatement reuseCount: 12, SELECT code, nytdiff FROM areacode WHERE (id=?)
> 12:00:51,891 INFO [STDOUT] PreparedStatement reuseCount: 10, SELECT COUNT(*) FROM statistics WHERE id=?
> 12:00:51,889 INFO [STDOUT] PreparedStatement reuseCount: 9, SELECT sequence.name, sequence.name, sequence.value FROM sequence WHERE name=?
> 12:00:51,785 INFO [STDOUT] PreparedStatement reuseCount: 9, SELECT COUNT(*) FROM unitstatistics WHERE id=?
> 12:00:51,782 INFO [STDOUT] PreparedStatement reuseCount: 9, SELECT COUNT(*) FROM unit WHERE id=?
> 12:00:51,780 INFO [STDOUT] PreparedStatement reuseCount: 9, SELECT COUNT(*) FROM building WHERE id=?
> 12:00:51,666 INFO [STDOUT] PreparedStatement reuseCount: 8, SELECT t0_v.id, t0_v.id, t0_v.nextVersion, t0_v.name, t0_v.reasonToBe, t0_v.displayName, t0_v.prod_content_id FROM versionedcontent t0_v WHERE (t0_v.name LIKE ?)
> 12:00:51,878 INFO [STDOUT] PreparedStatement reuseCount: 7, SELECT n.id, n.id, n.status, n.companyType, n.mechanism, n.otherReasonString, n.wasSuccessful, n.whenDate, n.toDo, n.checkedOut, n.done, n.contactName, n.contactInfo, n.owner, n.areacode, n.user_id, n.reason_id, n.companyid FROM notification n WHERE n.status = ? AND n.mechanism=? AND n.todo < ? ORDER BY n.todo LIMIT ?
> 12:00:51,621 INFO [STDOUT] PreparedStatement reuseCount: 5, SELECT id, id, whenDate, who, subject, mimeType, message, notification_id FROM notificationlog WHERE (notification_id=?)
> 12:00:51,624 INFO [STDOUT] PreparedStatement reuseCount: 4, SELECT version, whenCreated, parserCode, mime, data, creator, note, vc_id FROM content WHERE (id=?)
> 12:00:51,699 INFO [STDOUT] PreparedStatement reuseCount: 3, SELECT sequence.name, sequence.name, sequence.value FROM sequence WHERE name=?
> 12:00:51,612 INFO [STDOUT] PreparedStatement reuseCount: 2, SELECT DISTINCT t0_n.id, t0_n.id, t0_n.status, t0_n.companyType, t0_n.mechanism, t0_n.otherReasonString, t0_n.wasSuccessful, t0_n.whenDate, t0_n.toDo, t0_n.checkedOut, t0_n.done, t0_n.contactName, t0_n.contactInfo, t0_n.owner, t0_n.areacode, t0_n.user_id, t0_n.reason_id, t0_n.companyid FROM notification t0_n WHERE (t0_n.status = ? AND t0_n.mechanism = ? AND t0_n.wasSuccessful = FALSE)
> 12:00:51,609 INFO [STDOUT] PreparedStatement reuseCount: 2, SELECT nextVersion, name, reasonToBe, displayName, prod_content_id FROM versionedcontent WHERE (id=?)
> 12:00:51,604 INFO [STDOUT] PreparedStatement reuseCount: 2, SELECT t0_p.id, t0_p.id, t0_p.name, t0_p.value, t0_p.contact, t0_p.areacode FROM phone t0_p WHERE (t0_p.value LIKE ? AND t0_p.areacode IS NULL)
> 12:00:51,601 INFO [STDOUT] PreparedStatement reuseCount: 2, SELECT COUNT(*) FROM areacode WHERE id=?
> 12:00:51,593 INFO [STDOUT] PreparedStatement reuseCount: 1, SELECT users.id, users.id, users.name, users.password, users.features, users.version, users.comment, users.pwd_storage_style, users.deleted, users.old_name, users.deleted_date, users.contact, users.organization FROM users WHERE id=?
> 12:00:51,708 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT COUNT(*) FROM userlogin WHERE id=?
> 12:00:51,702 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT u.id, u.id, u.features, u.rent, u.status, u.street, u.street2, u.bedroom, u.bathroom, u.squareFeet, u.type, u.section8, u.pets, u.petsConditions, u.smoking, u.furniture, u.description, u.available, u.availableDate, u.marketDate, u.postDate, u.stoveType, u.fridge, u.washer, u.washerHookup, u.dryer, u.gasIncluded, u.electricIncluded, u.waterIncluded, u.electricHeat, u.gasHeat, u.oilHeat, u.electricWater, u.gasWater, u.taxCredit, u.subsidized, u.senior, u.seniorLicensed, u.leadPaint, u.securityDeposit, u.negotiableDeposit, u.negotiableDownpayment, u.minimumLease, u.maxoccupancyadult, u.maxOccupancyChild, u.air, u.flooring, u.dishWasher, u.slidingScale, u.slidinglow, u.alwaysAvailable, u.belowHUDFMR, u.trashCollection, u.yardMaintenance, u.otherInfo, u.viewLog, u.listLog, u.delete, u.deleteDate, u.lastUpdateDate, u.yearBuilt, u.version, u.deck, u.purchasemoreparking, u.trashpickup, u.promotion, u.amenities, u.p

arkingcomment, u.basementtype, u.parkingtype, u.yardmaintenancetype,
u.parkingspaces, u.parkingfee, u.trashpickupfee, u.yardmaintenancefee,
u.sliding_qualifiers, u.lastmodusername, u.forsaleprice,
u.minimum_down_payment, u.forsale_sliding_low, u.qualifiers,
u.upgrades_addons, u.homeowner_fee, u.income_based_ss_rent,
u.median_rent_20, u.median_rent_30, u.median_rent_40, u.median_rent_50,
u.median_rent_60, u.city, u.leadpaintunit, u.building, u.waitinglist_id,
u.zipcode FROM unit u , building b WHERE b.realtycompany = ? and
u.building=b.id and u.status=8 and u.features & 4::INT8 = 0::INT8
> 12:00:51,697 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT unit_webfiles.webfile_id, webfile.id, webfile.data, webfile.mimeType, webfile.lastModified, webfile.crunched FROM unit_webfiles, webfile WHERE (unit_webfiles.webfile_id=webfile.id) AND ((unit_webfiles.unit_id=?))
> 12:00:51,694 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT code, version FROM zipcode WHERE (id=?)
> 12:00:51,691 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT active, stateName, abbreviation, version, xmlsettings, xmlsettings_test FROM state WHERE (id=?)
> 12:00:51,688 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT features, name, version, xmlsettings, xmlsettings_test, state, primaryregion FROM city WHERE (id=?)
> 12:00:51,686 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT primarycity, overridesHUDFMR, availableUnits, bedroom0, bedroom1, bedroom2, bedroom3, bedroom4, bedroom5, bedroom6, bedroom7, bedroom8, forsalemodule, active, addable, leadpaintorganization, city FROM housingcity WHERE (id=?)
> 12:00:51,682 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT features, type, website, description, spanish, creditCheck, criminalCheck, fee, perAdult, negotiable, delete, deleteDate, allowed_idle_days, version, comment, organization, privateContact, defaultContact FROM realtycompany WHERE (id=?)
> 12:00:51,680 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT name, displayName, numberUnits, laundry, stories, busstop, publicxport_type, playground, access, schoolDistrict, version, contact, realtyCompany FROM building WHERE (id=?)
> 12:00:51,670 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT unit.id, unit.id, unit.features, unit.rent, unit.status, unit.street, unit.street2, unit.bedroom, unit.bathroom, unit.squareFeet, unit.type, unit.section8, unit.pets, unit.petsConditions, unit.smoking, unit.furniture, unit.description, unit.available, unit.availableDate, unit.marketDate, unit.postDate, unit.stoveType, unit.fridge, unit.washer, unit.washerHookup, unit.dryer, unit.gasIncluded, unit.electricIncluded, unit.waterIncluded, unit.electricHeat, unit.gasHeat, unit.oilHeat, unit.electricWater, unit.gasWater, unit.taxCredit, unit.subsidized, unit.senior, unit.seniorLicensed, unit.leadPaint, unit.securityDeposit, unit.negotiableDeposit, unit.negotiableDownpayment, unit.minimumLease, unit.maxoccupancyadult, unit.maxOccupancyChild, unit.air, unit.flooring, unit.dishWasher, unit.slidingScale, unit.slidinglow, unit.alwaysAvailable, unit.belowHUDFMR, unit.trashCollection, unit.yardMaintenance, unit.otherInfo

, unit.viewLog, unit.listLog, unit.delete, unit.deleteDate,
unit.lastUpdateDate, unit.yearBuilt, unit.version, unit.deck,
unit.purchasemoreparking, unit.trashpickup, unit.promotion,
unit.amenities, unit.parkingcomment, unit.basementtype,
unit.parkingtype, unit.yardmaintenancetype, unit.parkingspaces,
unit.parkingfee, unit.trashpickupfee, unit.yardmaintenancefee,
unit.sliding_qualifiers, unit.lastmodusername, unit.forsaleprice,
unit.minimum_down_payment, unit.forsale_sliding_low, unit.qualifiers,
unit.upgrades_addons, unit.homeowner_fee, unit.income_based_ss_rent,
unit.median_rent_20, unit.median_rent_30, unit.median_rent_40,
unit.median_rent_50, unit.median_rent_60, unit.city, unit.leadpaintunit,
unit.building, unit.waitinglist_id, unit.zipcode FROM unit WHERE id=?
> 12:00:51,606 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT contact.id, contact.id, contact.firstName, contact.middleName, contact.lastName, contact.organizationName, contact.version FROM contact WHERE id=?
> 12:00:51,597 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT notification_id, id, id, whenDate, who, subject, mimeType, message, notification_id FROM notificationlog WHERE (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?) OR (notification_id=?)
> 12:00:51,570 INFO [STDOUT] PreparedStatement reuseCount: 0, SELECT organization.id, organization.id, organization.name, organization.extension, organization.type FROM organization WHERE id=?
>
>
> ------------------------------------------------------------------------
>
>
>
>
> ----
> James Robinson
> Socialserve.com
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Edoardo Ceccarelli 2004-04-16 22:58:42 slow seqscan
Previous Message Tao Yang 2004-04-16 21:29:39 Out of memory exception