In testing Neil's PREPARE/EXECUTE patch on my test query, I found the
parser complains that this query is not valid when using current
sources. The error I get is:
psql:testorig.sql:1: ERROR: JOIN/ON clause refers to "xf2", which is
not part of JOIN
I think the sql is valid (at least it has
Neil Conway wrote:
> Hi all,
>
> I've attached an updated version of Karel Zak's pg_qcache patch, which
> adds PREPARE/EXECUTE support to PostgreSQL (allowing prepared SQL
> statements). It should apply cleanly against CVS HEAD, and compile
> properly -- beyond that, cross your fingers :-)
I wan
> Just explicitly prepared ones. Caching all queries opens a can of
> worms that I'd rather not deal with at the moment (volunteers to
> tackle this problem are welcome).
I definitely agree. I think that the optimisation possiblities offered to
the DBA for shared prepared statements are quite la
> No, VACUUM has the same transactional constraints as everyone else
> (unless you'd like a crash during VACUUM to trash your table...)
Seriously, you can run VACUUM in a transaction and rollback the movement of
a tuple on disk? What do you mean by same transactional constraints?
Chris
--
Gavin, I will do the legwork on this if you wish. I think we need to
use DefElem to store the COPY params, rather than using specific fields
in CopyStmt.
Would you send me your original patch so I am make sure I hit
everything. I can't seem to find a copy. If you would like to work on
it, I c
David, sorry you patch didn't make it into 7.2.X. That whole EINTR
discussion was quite complicated so I am not surprised we missed it.
The attached patch implements your ENITR test in cases that seems to
need it. I have followed the method we used for ENITRY in fe-misc.c.
--
On Sun, 14 Apr 2002 12:11:31 +0800
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> Does it cache all queries or just explicitly prepared ones?
Just explicitly prepared ones. Caching all queries opens a can of
worms that I'd rather not deal with at the moment (volunteers to
tackle this prob
Does it cache all queries or just explicitly prepared ones?
Does is check for cached queries all the time or just explicitly EXECUTED
ones?
Chris
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 6:47 A
Does it cache all queries or just explicitly prepared ones?
Does is check for cached queries all the time or just explicitly EXECUTED
ones?
Chris
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 6:47 A
In benchmarks that I have done in the past comparing performance of
Oracle and Postgres in our web application, I found that I got ~140
requests/sec on Oracle and ~50 requests/sec on postgres.
The code path in my benchmark only issues one sql statement. Since I
know that Oracle caches query p
RPMs for 7.2.1 are immediately available for download from
ftp://ftp.postgresql.org/pub/binary/v7.2.1/RPMS
Binary RPMs available are for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC, and
the source RPM is in SRPMS.
To rebuild on RedHat 7.x, simply rpm --rebuild if you have the necessary
develop
I am not seeing any jdbc build failure here. I am using:
Ant version 1.4 compiled on September 3 2001
---
Tatsuo Ishii wrote:
> Can someone please fix this? Building JDBC staffs in current has been
> broken for a
Can someone please fix this? Building JDBC staffs in current has been
broken for a while(7.2.x is ok). Maybe current JDBC build process
requires more recent version of ant than I have, I don't know. But if
so, that should be stated somewhere in the docs explicitly, I think.
/usr/bin/ant -buildfil
Hi all,
I've attached an updated version of Karel Zak's pg_qcache patch, which
adds PREPARE/EXECUTE support to PostgreSQL (allowing prepared SQL
statements). It should apply cleanly against CVS HEAD, and compile
properly -- beyond that, cross your fingers :-)
Please take a look at the code, play
Patch applied. Thanks.
---
Neil Conway wrote:
> On Fri, 12 Apr 2002 19:24:21 -0400
> "Neil Conway" <[EMAIL PROTECTED]> wrote:
> > When I built the current CVS code, both test-case exhibits the
> > problem quite obviously
On Sat, 13 Apr 2002 14:21:50 +0800
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> Could this cache mechanism be used to make views fast as well?
The current PREPARE/EXECUTE code will speed up queries that use
rules of any kind, including views: the query plan is cached after
it has been r
Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > > Having seen zero reports of any numeric
> > > failures since we installed it, and seeing it takes >10x times longer
> > > than the other tests, I think it should be paired back. Do we really
> > > need 10 tests of each complex function?
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> No, VACUUM has the same transactional constraints as everyone else
>> (unless you'd like a crash during VACUUM to trash your table...)
> But can't it do the SET TO NULL thing if it knows that the transaction
> that dropped the column has committed.
H
On Sat, 2002-04-13 at 17:29, Tom Lane wrote:
> [ way past time to change the title of this thread ]
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > OK, sounds fair. However, is there a more aggressive way of reclaiming the
> > space? The problem with updating all the rows to null
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> thought out way of predicting/limiting their size. (2) How the heck do
> you get rid of obsoleted cached plans, if the things stick around in
> shared memory even after you start a new backend? (3) A shared cache
> requires locking; content
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Basically I'd like to write
> CREATE FUNCTION name (args, ...) RETURNS type
> AS '...'
> LANGUAGE foo
> STATIC
> IMPLICIT CAST
> (where everything after RETURNS can be in random order).
No strong objection here; but you'
[ way past time to change the title of this thread ]
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> OK, sounds fair. However, is there a more aggressive way of reclaiming the
> space? The problem with updating all the rows to null for that column is
> that the on-disk size is doubled a
Christopher Kings-Lynne wrote:
> > Having seen zero reports of any numeric
> > failures since we installed it, and seeing it takes >10x times longer
> > than the other tests, I think it should be paired back. Do we really
> > need 10 tests of each complex function? I think one would do the tric
On Fri, 2002-04-12 at 03:04, Brian Bruns wrote:
> On 11 Apr 2002, Hannu Krosing wrote:
>
> > IIRC someone started work on modularising the network-related parts with
> > a goal of supporting DRDA (DB2 protocol) and others in future.
>
> That was me, although I've been bogged down lately, and hav
24 matches
Mail list logo
