Hi Simon,

Thanks for your comments.

The reason for those 5 options is to consider different means to cover the
Prepared Stmt requirement where the different stages of processing are
actually in different transactions. 

John Bartlett
Software Development Engineer
Fujitsu Australia Software Technology
14 Rodborough Road, Frenchs Forest NSW 2086
Tel: +61 2 9452 9161
Fax: +61 2 9975 2899
Web site: www.fastware.com

-----Original Message-----
[mailto:[EMAIL PROTECTED] On Behalf Of Simon Riggs
Sent: Tuesday, 23 January 2007 11:12 PM
To: FAST PostgreSQL
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Updateable cursors

On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:

> In the UPDATE or DELETE statements the 'WHERE CURRENT OF <cursor_name>' 
> clause results in the cursor name being placed in the UpdateStmt or 
> DeleteStmt structure. During the processing of the functions - 
> transformDeleteStmt() and transformUpdateStmt() - the cursor name is used
> obtain a pointer to the related Portal structure 

To support prepared statements we'd need to do this name lookup just
once, so that the Update/Delete stmt can record which Portal to look at
for the current tuple.

> and the tuple affected by 
> the current UPDATE or DELETE statement is extracted from the Portal, where
> has been placed as the result of a previous FETCH request. At this point
> the information for the UPDATE or DELETE statement is available so the 
> statements can be transformed into standard UPDATE or DELETE statements
> sent for re-write/planning/execution as usual.

> 2.5 Changes to the Executor
> -------------------------------
> There are various options that have been considered for this part of the 
> enhancement. These are described in the sections below.

> Option 1  MVCC Via Continuous Searching of Database
> The Executor is to be changed in the following ways:
> 1)    When the FETCH statement is executed the id of the resulting tuple
> extracted and passed back to the Portal structure to be saved to indicate
> cursor is currently positioned on a tuple.
> 2)    When the UPDATE or DELETE request is executed the tuple id
> FETCHed is held in the QueryDesc structure so that it can be compared with

> the tuple ids returned from the TidScan node processed prior to the actual

> UPDATE / DELETE node in the plan. This enables a decision to be made as to

> whether the tuple held in the cursor is visible to the UPDATE / DELETE 
> request according to the rules of concurrency. The result is that, at the 
> cost of repeatedly searching the database at each UPDATE / DELETE command,

> the hash table is no longer required.
> This approach has the advantage that there is no hash table held in memory
> on disk so it will not be memory intensive but will be processing

Do you have a specific example that would cause problems? It's much
easier to give examples that might cause problems and discuss those.

AFAICS in the straightforward case the Fetch will only return rows it
can see so update/delete should have no problems, iff the update/delete
is using a same or later snapshot than the cursor. I can see potential
problems with scrollable cursors.

So I'm not sure why there's a big need for any of the 5 options, yet.

  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 
693 481. It is confidential to the ordinary user of the email address to which 
it was addressed and may contain copyright and/or legally privileged 
information. No one else may read, print, store, copy or forward all or any of 
it or its attachments. If you receive this email in error, please return to 
sender. Thank you.

If you do not wish to receive commercial email messages from Fujitsu Australia 
Software Technology Pty Ltd, please email [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to