Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> ... If that's
> >> what we think we want, we'd better put it on the wish-list for 7.5.
>
> > If we had a Parse function, then we at phpPgAdmin could allow Reports to
> > contain parameters, and detect as such, and then w
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> ... If that's
>> what we think we want, we'd better put it on the wish-list for 7.5.
> If we had a Parse function, then we at phpPgAdmin could allow Reports to
> contain parameters, and detect as such, and then when they run their report,
>
> > It might possibly make sense for a libpq routine that exposes Parse
> > to actually do Parse followed by Describe Statement; that would allow
> > it to give back (a) an indication of the number and types of parameters
> > needed by the statement, and (b) an indication of the column set to be
>
Added to TODO:
* Allow PREPARE of cursors
---
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> >> I'm beginning to think that was a serious omission. I'm tempted to
> >> fix it, even though we're pa
Is there a TODO here? Text?
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What do you actually get back from a Parse request?
>
> Nothing. If successful, it creates a prepared statement ins
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Neither. I might look into it further later, but here's a patch to exit
> out of pgstat_initstats() if we're not collecting stats (attached).
Applied along with other fixes.
regards, tom lane
---(end of br
On Mon, 11 Aug 2003, Andrew Dunstan wrote:
>
> - Original Message -
> From: "Gavin Sherry" <[EMAIL PROTECTED]>
> > I am still researching ways of increasing performance of yacc parsers --
> > there is a very small amount of information on the Web concerning this --
>
> I know some peopl
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm beginning to think that was a serious omission. I'm tempted to fix
>> it, even though we're past feature freeze for 7.4. Comments?
> Seems pretty well isolated. If you're tallying votes, count me as a "yay".
Well, the early voting
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Tue, 12 Aug 2003, Tom Lane wrote:
>> I'm beginning to think that was a serious omission. I'm tempted to fix
>> it, even though we're past feature freeze for 7.4. Comments?
> Can you give an example of this usage of this API? I am wondering whether
>
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I wasn't interested in measuring the performance of yacc -- since I know
> it is bad. It was a basic test which wasn't even meant to be real
> world. It just seemed interesting that the numbers were three times slower
> than other databases I ran it on. He
Tom Lane wrote:
A Bind/Execute facility would need a pair of routines with signatures
very similar to PQexecParams/PQsendQueryParams --- they'd take a
prepared statement name instead of a query string, and they'd not need
an array of parameter type OIDs, but otherwise the same. I couldn't
come up
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> We could also think about providing an interface to do just Parse,
>> although this is inessential since you can set up a prepared statement
>> by PQexec'ing a PREPARE command.
> Wait just a minute! phpPgAdmin would love to be able to 'pars
Stephen Frost <[EMAIL PROTECTED]> writes:
> You probably know but I'll quickly outline it to point out the
> differences, as I see them, from the 'COPY' ability. Basically the user
> defines their own C structure and then malloc's an array of them. The
> user then tells the database the type, off
> This leaves us with a bit of a problem, though, because there isn't
> any libpq API that allows access to this speedup. I put in a
> routine to support Parse/Bind/Execute so that people could use
> out-of-line parameters for safety reasons --- but there's no
> function to do Bind/Execute against
> > Wait just a minute! phpPgAdmin would love to be able to 'parse' arbitrary
> > sql entered by the user to separate semi-coloned queries, identify various
> > types of queries, etc. What would a Parse call allow us to do?
>
> Hm. I was about to say "very little that you can't do with a PREPARE
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Of course the obvious way of getting rid of the parser overhead is not
> to parse everytime --- viz, to use prepared statements.
I think this would be nice to have too... On a similar note (I think
anyway) I wasn't able to find any functions for bulk dumps
Stephen Frost <[EMAIL PROTECTED]> writes:
> ... If libpq grabs the entire result in one go then that may
> actually cause a problem for me when I start to move things from Oracle
> to postgres since the clients don't always have much memory available.
It does that in an ordinary SELECT. The custo
I said:
> I doubt a hash is worth maintaining, because the active tabstat entries
> should only be for tables that are being touched in the current command
> (thus, there are not more than six in your example). I'm not sure why
> it takes so much time to look through six entries though ...
I repl
I did some basic profiling of CVS HEAD after having read Bruce's post the
other day: When did we get so fast. It seemed to me that the number of
inserts per second wasn't actually all that high so I had a look at some
numbers:
% cumulative self self total
time seconds s
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What do you actually get back from a Parse request?
Nothing. If successful, it creates a prepared statement inside the
server.
It might possibly make sense for a libpq routine that exposes Parse
to actually do Parse followed by Describe State
Gavin Sherry <[EMAIL PROTECTED]> writes:
> but pgstat_initstats() caught my eye. This gets called about 6 times per
> insert (I did 10 inserts) and the major cost appears to relate to the
> linear pgStatTabstatMessages. The comparative performance of
> hash_search() suggests that pgStatTabstatM
> This leaves us with a bit of a problem, though, because there isn't any
> libpq API that allows access to this speedup. I put in a routine to
> support Parse/Bind/Execute so that people could use out-of-line
> parameters for safety reasons --- but there's no function to do
> Bind/Execute against
Tom Lane wrote:
I'm beginning to think that was a serious omission. I'm tempted to fix
it, even though we're past feature freeze for 7.4. Comments?
Seems pretty well isolated. If you're tallying votes, count me as a "yay".
Joe
---(end of broadcast)-
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I'm beginning to think that was a serious omission. I'm tempted to
>> fix it, even though we're past feature freeze for 7.4. Comments?
> On a quasi-similar note (and unless I've missed how to do this), you
> can't create a cursor from a prepared sta
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > You probably know but I'll quickly outline it to point out the
> > differences, as I see them, from the 'COPY' ability. Basically the user
> > defines their own C structure and then malloc's an array of them. Th
> We could also think about providing an interface to do just Parse,
> although this is inessential since you can set up a prepared statement
> by PQexec'ing a PREPARE command.
Wait just a minute! phpPgAdmin would love to be able to 'parse' arbitrary
sql entered by the user to separate semi-colon
> world. It just seemed interesting that the numbers were three times slower
> than other databases I ran it on. Here is the script which generates the
You were comparing against databases with similar safety nets to
guarantee against dataloss?
signature.asc
Description: This is a digitally sig
On Tue, Aug 12, 2003 at 03:36:07PM -0400, Tom Lane wrote:
> This leaves us with a bit of a problem, though, because there isn't any
> libpq API that allows access to this speedup. I put in a routine to
> support Parse/Bind/Execute so that people could use out-of-line
> parameters for safety reaso
On Tue, 12 Aug 2003, Tom Lane wrote:
> This leaves us with a bit of a problem, though, because there isn't any
> libpq API that allows access to this speedup. I put in a routine to
> support Parse/Bind/Execute so that people could use out-of-line
> parameters for safety reasons --- but there's no
On Tue, 12 Aug 2003, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > but pgstat_initstats() caught my eye. This gets called about 6 times per
> > insert (I did 10 inserts) and the major cost appears to relate to the
> > linear pgStatTabstatMessages. The comparative performance o
On Tue, 12 Aug 2003, Tom Lane wrote:
> I have just finished running some experiments that compared a series of
> INSERTs issued via PQexec() versus preparing an INSERT command and then
> issuing new-FE-protocol Bind and Execute commands against the prepared
> statement. With a test case like the
On Tue, 12 Aug 2003, Rod Taylor wrote:
> > world. It just seemed interesting that the numbers were three times slower
> > than other databases I ran it on. Here is the script which generates the
>
> You were comparing against databases with similar safety nets to
> guarantee against dataloss?
I
- Original Message -
From: "Gavin Sherry" <[EMAIL PROTECTED]>
> I am still researching ways of increasing performance of yacc parsers --
> there is a very small amount of information on the Web concerning this --
I know some people who will tell you that the best way of improving
perform
33 matches
Mail list logo
