Thread

1. Re: [HACKERS] Postgres Speed or lack thereof

   Tom Samplonius <tom@sdf.com> — 1999-01-18T03:23:15Z

   On Sun, 17 Jan 1999, Tom Lane wrote:
   
   > Tom <tom@sdf.com> writes:
   > > On Sun, 17 Jan 1999, Tom Lane wrote:
   > >> I tried this myself and found that wrapping BEGIN/END around a series of
   > >> INSERT statements didn't make much difference at all.
   > 
   > >   Using what API?
   > 
   > Sorry, I neglected to specify that it was psql (being driven by
   > hand-trimmed pg_dump scripts).
   
     This also wouldn't you give you any benefit from "prepare" that would
   speed up repeated executions of the same statement.  PostgreSQL does allow
   statements to be prepared right?  If it doesn't, chances are COPY has a
   way of doing it.  It saves a lot of parsing and planning time.
   
   > > Some APIs control autocommit for you, so execing
   > > "BEGIN" and "END" commands may not do anything.
   > 
   > That's not the case for psql.  If it were, I would have measured no
   > difference in speed, rather than a small difference.
   > 
   > 			regards, tom lane
   
   Tom
   
   
   

2. Re: [HACKERS] Postgres Speed or lack thereof

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-01-18T04:21:45Z

   Tom <tom@sdf.com> writes:
   > On Sun, 17 Jan 1999, Tom Lane wrote:
   >> I tried this myself and found that wrapping BEGIN/END around a series of
   >> INSERT statements didn't make much difference at all.
   
   >   Using what API?
   
   Sorry, I neglected to specify that it was psql (being driven by
   hand-trimmed pg_dump scripts).
   
   > Some APIs control autocommit for you, so execing
   > "BEGIN" and "END" commands may not do anything.
   
   That's not the case for psql.  If it were, I would have measured no
   difference in speed, rather than a small difference.
   
   			regards, tom lane
   
   

3. Re: [HACKERS] Postgres Speed or lack thereof

   Michael Meskes <michael.meskes@usa.net> — 1999-01-18T07:49:24Z

   On Sun, Jan 17, 1999 at 07:23:15PM -0800, Tom wrote:
   >   This also wouldn't you give you any benefit from "prepare" that would
   > speed up repeated executions of the same statement.  PostgreSQL does allow
   > statements to be prepared right?  If it doesn't, chances are COPY has a
   
   Since when? I thought we're still looking for someone to implement it, i.e.
   at least the PREPARE statement.
   
   Michael
   -- 
   Michael Meskes                         | Go SF 49ers!
   Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
   Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
   Email: Michael.Meskes@gmx.net          | Use PostgreSQL!
   
   

4. Re: [HACKERS] Postgres Speed or lack thereof

   Vadim Mikheev <vadim@krs.ru> — 1999-01-19T02:15:01Z

   Michael Meskes wrote:
   > 
   > On Sun, Jan 17, 1999 at 07:23:15PM -0800, Tom wrote:
   > >   This also wouldn't you give you any benefit from "prepare" that would
   > > speed up repeated executions of the same statement.  PostgreSQL does allow
   > > statements to be prepared right?  If it doesn't, chances are COPY has a
   > 
   > Since when? I thought we're still looking for someone to implement it, i.e.
   > at least the PREPARE statement.
   
   1. PG can handle prepared queries.
      Parser & Planner can parse/plan (i.e. prepare) query with
      parameters once, so such prepared query can be executed 
      many times by executor without parser/planner invocation.
   2. We have to implement some interface to use this ability.
   
   Vadim
   
   

5. Prepared statements (was: Postgres Speed or lack thereof)

   Taral <taral@cyberjunkie.com> — 1999-01-19T02:26:40Z

   On Mon, 18 Jan 1999, Vadim Mikheev wrote:
   >1. PG can handle prepared queries.
   >   Parser & Planner can parse/plan (i.e. prepare) query with
   >   parameters once, so such prepared query can be executed 
   >   many times by executor without parser/planner invocation.
   >2. We have to implement some interface to use this ability.
   
   Yes, I need prepared statements for CORBA, too.
   
   Taral
   
   

6. Re: [HACKERS] Postgres Speed or lack thereof

   Michael Meskes <michael.meskes@usa.net> — 1999-01-19T08:34:26Z

   On Tue, Jan 19, 1999 at 09:15:01AM +0700, Vadim Mikheev wrote:
   > 1. PG can handle prepared queries.
   >    Parser & Planner can parse/plan (i.e. prepare) query with
   >    parameters once, so such prepared query can be executed 
   >    many times by executor without parser/planner invocation.
   > 2. We have to implement some interface to use this ability.
   
   I see. Thanks.
   
   Michael
   -- 
   Michael Meskes                         | Go SF 49ers!
   Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
   Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
   Email: Michael.Meskes@gmx.net          | Use PostgreSQL!
   
   

7. Re: [HACKERS] Prepared statements (was: Postgres Speed or lack thereof)

   Peter Mount <peter@retep.org.uk> — 1999-01-19T21:05:49Z

   On Mon, 18 Jan 1999, Taral wrote:
   
   > On Mon, 18 Jan 1999, Vadim Mikheev wrote:
   > >1. PG can handle prepared queries.
   > >   Parser & Planner can parse/plan (i.e. prepare) query with
   > >   parameters once, so such prepared query can be executed 
   > >   many times by executor without parser/planner invocation.
   > >2. We have to implement some interface to use this ability.
   > 
   > Yes, I need prepared statements for CORBA, too.
   
   This would improve JDBC's PreparedStatement as well.
   
   -- 
          Peter T Mount peter@retep.org.uk
         Main Homepage: http://www.retep.org.uk
   PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
    Java PDF Generator: http://www.retep.org.uk/pdf