Thank you James.
Will switch over to PreparedStatement. Interestingly, in some load tests,
prepared statements did not offer any significant advantage. But as I
understand, this is going to change soon.
Best regards,Sumit
From: James Taylor <[email protected]>
To: user <[email protected]>
Cc: Sumit Nigam <[email protected]>
Sent: Tuesday, September 15, 2015 10:12 AM
Subject: Re: Phoenix with PreparedStatement
Sumit,To add to what Samarth said, even now PreparedStatements help by saving
the parsing cost. Soon, too, for UPDATE VALUES, we'll also avoid recompilation
when using a PreparedStatement. I'd encourage you to use them.Thanks,James
On Mon, Sep 14, 2015 at 9:32 PM, Samarth Jain <[email protected]> wrote:
Hi Sumit,
Phoenix doesn't cache query plans as of yet. Once we move over to Calcite
parser and optimizer (which is a work in progress), we will hopefully start
doing that which is when your suggested approach of using PreparedStatement
with bind params would be beneficial.
- Samarth
On Mon, Sep 14, 2015 at 9:13 PM, Sumit Nigam <[email protected]> wrote:
Hello,
I am using Phoenix 4.5 with Hbase 0.98.1.
PreparedStatement is preferred in case of say Oracle, etc. to help with
effective use of query plans (with bind params). Does it also have same
guarantees with Phoenix or does the Phoenix query engine treat both Statement
and Prepared statement equally and I can use any of these with similar
performance characteristics?
Thanks,Sumit
