Skip site navigation (1) Skip section navigation (2)

Re: queries run twice unless 'parse statements' checked?

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Johann" <johann(at)tygerpos(dot)com>, <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: queries run twice unless 'parse statements' checked?
Date: 2005-02-09 09:16:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org 
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Johann
> Sent: 07 February 2005 04:20
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: [ODBC] queries run twice unless 'parse statements' checked?
> Running PostgreSQL 8.0, client is Visual Basic program using 
> ADO, test case 
> has one adodc and a bound grid.
> Queries involving a 188,000 row table were slow, even when 
> query was on 
> single value in uniquely keyed index.
> Turns out - from checking the plsqlodbc file, it was 
> executing the query 
> once like I said:
> select something from somewhere where thing=value
> [returning one row]
> then it ran the query again without the where clause [really!]
> SELECT something FROM somewhere (The second query had the 
> keywords turned 
> to upper case, if that helps identify what's going on.)
> [returning 188,000 rows]
> Naturally, this made things run slowly.  I fiddled around and 
> eventually 
> found that by checking "Parse Statements", this behavior stopped.
> Anyway - is it supposed to work this way?

I cannot reproduce this behaviour here using a simple ADO recordset -
but can with the ADODC. My guess is that it is running the query again
to get column definitions (which happens automatically - and doubtless
more efficiently - with parse turned on) so that it can figure out how
to build update queries etc.

Regards, Dave,

pgsql-odbc by date

Next:From: Karol SzkudlarekDate: 2005-02-09 11:48:26
Subject: Re: 500 times slower
Previous:From: Dave PageDate: 2005-02-09 07:10:10
Subject: Re: Unix domain socket

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group