I guess we had this discussion before but I have just gone through the
general list and I have encountered a problem I had a least VERY often
before.
Sometimes the planner does not find the best way through a query.
Looking at the problem of query optimization it is pretty obvious that
things
Is it possible to get rid of the "t_natts" fields in the tuple header? Is this field
only for "alter table add/drop" support? Then it might
possible to get rid of it and put the "t_natts" field in the page header, not the
tuple header, if it can be assured that when updating/inserting
records on
Barry Lind wrote:
> Did anything come of this discussion on whether SET initiates a
> transaction or not?
SET does not start a multi-statement transaction when autocommit is off.
> In summary what is the right way to deal with setting autocommit in clients?
I guess just 'set autocommit to on'
Did anything come of this discussion on whether SET initiates a
transaction or not?
In summary what is the right way to deal with setting autocommit in clients?
thanks,
--Barry
Original Message
Subject: Re: [JDBC] Patch for handling "autocommit=false" in postgresql.conf
Date
OK, I have applied the following patch which should fix the problem by
preventing tv_sec from becoming negative.
---
Bruce Momjian wrote:
> Denis A Ustimenko wrote:
> > Hello Bruce!
> >
> > You have patched fe-connect.c an
Denis A Ustimenko wrote:
> Hello Bruce!
>
> You have patched fe-connect.c and dropeed out one check in line 1078:
>
> < while (rp == NULL || remains.tv_sec > 0 || (remains.tv_sec == 0 && remains.tv_usec
>> 0))
> ---
> > while (rp == NULL || remains.tv_sec > 0 || remains.tv_usec > 0)
>
> As I u
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Schema handling - ready? interfaces? client apps?
> > Drop column handling - ready for all clients, apps?
>
> How will delaying 7.3 remedy either of these issues?
>
> > Get bison upgrade on postgresql.org for ecpg only (Marc)
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Schema handling - ready? interfaces? client apps?
> Drop column handling - ready for all clients, apps?
How will delaying 7.3 remedy either of these issues?
> Get bison upgrade on postgresql.org for ecpg only (Marc)
Now that bison 1.50 is out, this sh
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On 10 Oct 2002, Neil Conway wrote:
> > Compiled with '-DBUFFER_SIZE=256 -O2', I get the following results in
> > seconds:
> >
> > MemSet(): ~9.6
> > memset(): ~19.5
> > __builtin_memset(): ~10.00
>
> I ran the same code. I do not understand the results
Oh, that's right. I had forgotten that it wasn't for general PostgreSQL
use. Since it's a ecpg deal only, I guess I remove my objection.
Greg
On Thu, 2002-10-10 at 09:18, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > Can we please hold off until bison 1.50 becomes a defacto
Greg Copeland wrote:
-- Start of PGP signed section.
> Can we please hold off until bison 1.50 becomes a defacto? It will be a
> matter of weeks before distros offer this as an upgrade package let
> alone months before distros offer this as a standard. Seems like these
> changes are ideal for a
Greg Copeland <[EMAIL PROTECTED]> writes:
> Can we please hold off until bison 1.50 becomes a defacto?
We don't have a whole lot of choice, unless you prefer releasing a
broken or crippled ecpg with 7.3.
In practice this only affects people who pull sources from CVS, anyway.
If you use a tarball
On 10 Oct 2002, Neil Conway wrote:
> Well, I'd assume any C library / compiler of half-decent quality on
> any platform would provide assembly optimized versions of common
> stdlib functions like memset().
>
> While playing around with memset() on my machine (P4 running Linux,
> glibc 2.2.5, GCC
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was looking for consistency so we could have things ready if we
> > tighten up in 7.4. I believe someone volunteered to fix them all so I
> > figured we should do that.
>
> Someone did volunteer, but I haven't seen results. My po
Here are the open items. There are only a few major ones left. I would
like to get those done so we can shoot for a final release perhaps at
the end of October.
---
P O S T G R E S Q L
On 10 Oct 2002 at 15:30, Manfred Koizar wrote:
> On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
> >here is an implementation of a set of user types: char3, char4,
> >char10.
>
> New version available. As I don't want to spam the list with various
> versions until I get it right eventually, you ca
Can we please hold off until bison 1.50 becomes a defacto? It will be a
matter of weeks before distros offer this as an upgrade package let
alone months before distros offer this as a standard. Seems like these
changes are ideal for a release after next (7.5/7.6) as enough time will
of gone by f
On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
>here is an implementation of a set of user types: char3, char4,
>char10.
New version available. As I don't want to spam the list with various
versions until I get it right eventually, you can get it from
http://members.aon.at/pivot/pg/fixchar20021010
Hello,
which global variable is the path of postgresql binary? such as /usr/local/pgsql/bin
I only find pg_pathbname stand for postgres full pathname.
thank you in advance.
Jinqiang Han
---(end of broadcast)---
TIP 1: subscribe and un
19 matches
Mail list logo
