On Wed, May 04, 2005 at 09:04:30AM -0400, Steve Sapovits wrote:
> Scott T. Hildreth wrote:
>
> >As Tim said, look at the RowCacheSize, I have seen big speed gains
> >by increasing this attribute.
>
> We do use that and I have also seen decent (maybe not big) gains.
> The big problem we have with
As Tim said, look at the RowCacheSize, I have seen big speed gains
by increasing this attribute.
On Wed, 2005-05-04 at 10:38 +0100, Tim wrote:
> On Wed, May 04, 2005 at 02:18:02AM -0400, Steve Sapovits wrote:
> >
> > >I meant to also note that the job in question is all SELECTs --
> > >it only pu
Scott T. Hildreth wrote:
As Tim said, look at the RowCacheSize, I have seen big speed gains
by increasing this attribute.
We do use that and I have also seen decent (maybe not big) gains.
The big problem we have with it is maintaining a good setting as
our data grows, since we usually set it to a n
On Wed, May 04, 2005 at 02:18:02AM -0400, Steve Sapovits wrote:
>
> >I meant to also note that the job in question is all SELECTs --
> >it only pulls data and does not update any tables. If the
> >"almost there" is known to cover SELECTs that would be good to
> >know.
>
> I did some reading and
On Tue, May 03, 2005 at 04:28:10PM -0700, Job Miller wrote:
> the lack of it really limits perl's utility for any serious data loading
> operations that require performance. if you look at the extended sql trace
> of a:
>
> parse
> loop
> execute(x)
> end loop;
>
> you will see that it using
I meant to also note that the job in question is all SELECTs --
it only pulls data and does not update any tables. If the
"almost there" is known to cover SELECTs that would be good to
know.
I did some reading and from what I can tell, Oracle's array
interface would not have any effect on the typ
I meant to also note that the job in question is all SELECTs --
it only pulls data and does not update any tables. If the
"almost there" is known to cover SELECTs that would be good to
know.
--
Steve Sapovits [EMAIL PROTECTED]
Job wrote:
I am sure it isn't real easy to do, otherwise Tim would have
> done it long ago.
Tim responded:
Actually I've been moving the code in that direction for several
releases. It's (possibly) most of the way there. Patches welcome.
This is good news. I'll take a look and see what sense I ca
the lack of it really limits perl's utility for any serious data loading
operations that require performance. if you look at the extended sql trace of
a:
parse
loop
execute(x)
end loop;
you will see that it using single row executes. Unfortunately there is no magic
going on behind the scene
I'm sure it will be someday, I know that execute_array is in DBI.
I believe DBD::Pg uses array inserts. As far as I know, DBD::Oracle does
not use the Array Processing yet.
On Tue, 2005-05-03 at 15:35 -0400, Steve Sapovits wrote:
> Scott T. Hildreth wrote:
>
> > Not yet.
>
> Thanks for the quick
Scott T. Hildreth wrote:
I'm sure it will be someday, I know that execute_array is in DBI.
I believe DBD::Pg uses array inserts. As far as I know, DBD::Oracle does
not use the Array Processing yet.
Maybe Mr. Bunce can comment on when someday is? ;-)
--
Steve Sapovits[EMAIL PROTECTED]
Not yet.
On Tue, 2005-05-03 at 15:10 -0400, Steve Sapovits wrote:
> A question from a DBA here: Does DBD::Oracle use Oracle's
> "array interface" to interface to Oracle?
>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
A question from a DBA here: Does DBD::Oracle use Oracle's
"array interface" to interface to Oracle?
--
Steve Sapovits[EMAIL PROTECTED]
13 matches
Mail list logo
