On Mon, 2003-04-07 at 14:59, Ron Peacetree wrote:
Two phase execution and two phase commit are two different concepts.
Two phase execution splits the execution of queries explicitly into a
"do all the book keeping and setup stuff before execution" phase and
an actual execution phase. The benefit is that if you are going to
say, step through a largish table in chunks, doing the same query on
each chunk, two phase execution allows the DB to do everything (syntax
checking, query planning, blah, blah) except the actual execution
=once= and reuse it for each subsequent chunk.
If "stepping through a largish table in chunks" is implemented as a
single SQL query, PostgreSQL already does this internally (the parsing,
planning, rewriting, and execution phases are distinct operations inside
the backend).

If the stepping is done as a bunch of similar queries, you can use
prepared queries (as of PostgreSQL 7.3) to do the parsing, planning and
rewriting only once, and then reuse the query plan multiple times.
It also helps parallel performance since
you can hand the "blessed" set up query plan to multiple processes and
those processes can focus on just getting work done.
Prepared queries are per-backend as of PostgreSQL 7.3, so this can't be
done (and I'm a little skeptical that it would be very useful...)

Cheers,

Neil

Search Discussions

  • Jan Wieck at Apr 9, 2003 at 2:14 pm

    Ron Peacetree wrote:
    [...]
    The lack of two phase =commit= is a also a potential performance hit
    in comparison to DB products that have it, but the more important
    issue there is that there are SMP/distributed apps that really can't
    work acceptably unless a DB product has two phase commit.

    The three "biggies" in DB land, SQL Server, Oracle, and DB2, have both
    features. I suspect that PostgreSQL will need to as well...
    Ron, do you actually have some ideas how to do 2 phase commits?
    Especially things like how to re-lock during startup after a crash and
    the like? Or is your knowledge in reality only buzzwords collected from
    high glossy tradeshow flyers?


    Jan

    --
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me. #
    #================================================== JanWieck@Yahoo.com #
  • Ron Peacetree at Apr 9, 2003 at 4:37 pm
    "Jan Wieck" <JanWieck@Yahoo.com> wrote in message
    news:3E942A99.A6102F2D@Yahoo.com...
    Ron Peacetree wrote:
    [...]
    The lack of two phase =commit= is a also a potential performance
    hit
    in comparison to DB products that have it, but the more important
    issue there is that there are SMP/distributed apps that really
    can't
    work acceptably unless a DB product has two phase commit.

    The three "biggies" in DB land, SQL Server, Oracle, and DB2, have
    both
    features. I suspect that PostgreSQL will need to as well...
    Ron, do you actually have some ideas how to do 2 phase commits?
    Especially things like how to re-lock during startup after a crash and
    the like? Or is your knowledge in reality only buzzwords collected from
    high glossy tradeshow flyers?
    If "some ideas" means "do I know how to code it into PostgreSQL right
    now", the answer is no. If "some ideas" means "do I understand the
    general problem at a technical level well enough to be thinking about
    the algorithms and datastructures needed to support the functionality"
    the answer is yes.

    So I'd say a fair response to your questions is that my knowledge is
    in between the two extremes you've described, but probably closer to
    the first than the second ;-). We can have a private email discussion
    on the topic if you wish.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 8, '03 at 7:55p
activeApr 9, '03 at 4:37p
posts3
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase