Mark Kirkwood wrote:
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I don't know if this is yet another one, but happened to rebuild
7.3.12 on a FreeBSD 6.0 box today and I notice that it fails float8
regression test (geometry does too but that is marked as ignorable).
7.3 is
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I can't find any information of syntax for ANSI Conformance F262, F263.
Has
> somebody any information about this points: Extended CASE expression,
comma
> separated predicates in simple case expression
There are no such feature IDs listed in ei
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I don't know if this is yet another one, but happened to rebuild 7.3.12
on a FreeBSD 6.0 box today and I notice that it fails float8 regression
test (geometry does too but that is marked as ignorable).
7.3 is too old to know that fre
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> My point is, message xyz is immediately delivered or not is not very
> cleary described in the docs.
> For example in "simple" quries at the completion of the commands
> CommandComplete is immediately delivered despite it's not cleary
> stated in the docs.
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > However a extended query "Execute" does not return CommandComplete
> > (note: ErrorResponse will be returned if an error occurs). Although
> > the doc says " Therefore, an Execute phase is always terminated by the
> > appearance of exactly one of these
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I don't know if this is yet another one, but happened to rebuild 7.3.12
> on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> test (geometry does too but that is marked as ignorable).
7.3 is too old to know that freebsd beyond 4.x
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> However a extended query "Execute" does not return CommandComplete
> (note: ErrorResponse will be returned if an error occurs). Although
> the doc says " Therefore, an Execute phase is always terminated by the
> appearance of exactly one of these messages:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I just read an article on LWN.net about the usage of self-modifying code
> for selecting the optimum code for a given operation at run time.
That went out with hula hoops, I think. For sure the security
implications of making your code segment writable
On Wed, 14 Dec 2005, Luke Lonergan wrote:
>
> Overall - I'd say that the BSD routine is showing the best overall results
> when the scale test is included. The qsortG routine has some significantly
> better performance in certain cases at smaller sort set sizes - it could
> probably be improved f
I just read an article on LWN.net about the usage of self-modifying code
for selecting the optimum code for a given operation at run time. This
is probably not a highly portable technique, but Linux has definitions
for i386 and the amd64 archs, so that would cover the most common
scenarios.
This
Qingqing,
On 12/13/05 10:28 AM, "Qingqing Zhou" <[EMAIL PROTECTED]> wrote:
> http://www.cs.toronto.edu/~zhouqq/postgresql/sort/sort.html
>
> The source tar ball and linux 2.4G gcc 2.96 test results is on the page.
> There is a clear loser glibc, not sure qsortB or qsortG which is better.
Great
Thank you Tom. I will test it and reply the result as information for other. But it may a week for that cause many work in end of year.>>> Tom Lane <[EMAIL PROTECTED]> 12/14/2005 22:06:33 >>>"Premsun Choltanwanich" <[EMAIL PROTECTED]> writes:> I think I use contrib/lo type for manage lo. What is
I've spent some time looking into how we can improve our planning of outer
joins. The current planner code slavishly follows the syntactic join
order, which can lead to quite bad plans. The reason it does this is that
in some cases altering the join order of outer joins can change the
results. H
If it was me I'd just copy the pg_dump way of doing things...
To the extent possible, I'd like to preserve the exact functionality
(or lack thereof) of previous versions. Would this be possible that
way?
Don't see it'd be too hard. All pg_dump basically does is this:
if (version <= 7.3) {
On Thu, Dec 15, 2005 at 09:20:46AM +0800, Christopher Kings-Lynne wrote:
> >Neil Conway suggested something like a get_function_list(), which I
> >presume would be called on connect, and would be version-aware.
> >Does this seem like a good idea? If so, what might an
> >implementation look like?
There were quite some proposals about additional triggers (on
connect/disconnnect) around, I wonder if some kind of
schema/database-level trigger could be used for DDL logging.
Or, "global triggers" where you can have a trigger that is executed upon
ANY DML or DDL...
Chris
What I would like to see is some builtin functions that give me the
table's DDL, just as pg_dump does. Extra nice would be complementary
functions that also give me skeleton select statements for each table or
view.
Yeah, what I first thought David was proposing was a consolidated view
simila
Examining why psql won't do sensible stuff with COPY BINARY, I realized
that psql still uses PQgetline, which is marked obsolete since 7.4.
Is this intentional or just a "never reviewed because it works"?
There wasn't any obvious bang for the buck in rewriting it.
The obvious one (and why I s
I submitted a patch a while back to change that but I withdrew it
because I wasn't 100% confident I'd done it right.
Here is the link to it:
http://archives.postgresql.org/pgsql-patches/2005-03/msg00242.php
It's probably 99% there - just a bit of checking.
Chris
Andreas Pflug wrote:
Examinin
Neil Conway suggested something like a get_function_list(), which I
presume would be called on connect, and would be version-aware. Does
this seem like a good idea? If so, what might an implementation look
like? I know C isn't all that great for function overloading, so do
we want to keep all t
Hi,
I have difficulties with extended queries and pgpool combo.
the background:
After sending a query to the backend, pgpool waits for a response from
the backend so that pgpool can make sure that the query
completes. This is necessary since pgpool needs to keep the order of
SQL commands (especi
Ühel kenal päeval, K, 2005-12-14 kell 01:52, kirjutas David Fetter:
> Folks,
>
> I'm trying to come up with a design for \ commands in psql in 8.2.
> 8.1 broke just about every \ command because they now depend on roles,
> which is great for 8.1 or better, but not so good if you're connecting
> to
Jim C. Nasby wrote:
On Mon, Dec 12, 2005 at 10:39:47PM -0500, Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I think I'd just delete lines 464-470 in
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-auth.c?annotate=1.71
I confirmed that this is the patc
Gavin Sherry írta:
On Thu, 15 Dec 2005, Gavin Sherry wrote:
On Wed, 14 Dec 2005, Zoltan Boszormenyi wrote:
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
$ time echo "select * from v_invoice_browse where code||inv_no =
'CARO20020'" | dbaccess
On Thu, 15 Dec 2005, Gavin Sherry wrote:
> On Wed, 14 Dec 2005, Zoltan Boszormenyi wrote:
>
> > Tom Lane írta:
> >
> > >Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> > >
> > >
> > >>$ time echo "select * from v_invoice_browse where code||inv_no =
> > >>'CARO20020'" | dbaccess db
> > >>
> >
On Wed, 14 Dec 2005, Zoltan Boszormenyi wrote:
> Tom Lane írta:
>
> >Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> >
> >
> >>$ time echo "select * from v_invoice_browse where code||inv_no =
> >>'CARO20020'" | dbaccess db
> >>
> >>
> >
> >
> >
> >>Is there a way to speed this operation up?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn van Oosterhout wrote:
> On Mon, Dec 12, 2005 at 06:26:25PM -0200, Francisco Figueiredo Jr. wrote:
>>
>>
Hi all,
Yesterday I received a reply from Tom Lane who confirmed the bug and
promptly replied me with a patch!! :)
Thank you very much
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
$ time echo "select * from v_invoice_browse where code||inv_no =
'CARO20020'" | dbaccess db
Is there a way to speed this operation up?
Make an expression index on "code||inv_no", if you think this case is
im
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
There wasn't any obvious bang for the buck in rewriting it.
Well a non-binary copy could take as much as 5 times as much as a binary
copy. I hit this when COPYing 1.5GB of data, getting a 6.6GB file. This
made the
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Dec 13, 2005 at 11:33:20PM -0500, Tom Lane wrote:
and I don't even see the argument for doing it via a table rather
than via the postmaster log.
Simple. Postmaster logs can roll over or otherwise be lost without
damaging th
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There wasn't any obvious bang for the buck in rewriting it.
> Well a non-binary copy could take as much as 5 times as much as a binary
> copy. I hit this when COPYing 1.5GB of data, getting a 6.6GB file. This
> made the 100MBit LAN c
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Examining why psql won't do sensible stuff with COPY BINARY, I realized
that psql still uses PQgetline, which is marked obsolete since 7.4.
Is this intentional or just a "never reviewed because it works"?
There wasn't any obvious ban
>> Ofcourse, this is another can of worms. To do this you would have to be
>> able to have the failed query provide hints to the planner telling it
>> where it went wrong. Now, it may be possible to provide (via
>> post-mortem of an execution) a list of actual selectivites like:
>
> Just being able
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Dec 13, 2005 at 11:33:20PM -0500, Tom Lane wrote:
and I don't even see the argument for doing it via a table rather
than via the postmaster log.
Simple. Postmaster logs can roll over or otherwise be lost without
damaging the D
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> $ time echo "select * from v_invoice_browse where code||inv_no =
> 'CARO20020'" | dbaccess db
> Is there a way to speed this operation up?
Make an expression index on "code||inv_no", if you think this case is
important enough to be worth maint
Hi,
I am trying to prove whether PostgreSQL is faster than Informix
so I can feed the management with numbers.
In our system, there is an invoice browser view, an UNION of 12
different tables. (Yes, there are 12 different invoices, like new or
second-hand cars, warranty, service, etc, with in/ou
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What I would like to see is some builtin functions that give me the
> table's DDL, just as pg_dump does. Extra nice would be complementary
> functions that also give me skeleton select statements for each table or
> view.
Yeah, what I first thought D
Tom Lane wrote:
Simple. Postmaster logs can roll over or otherwise be lost without
damaging the DB. This would provide a non-volatile log of DDLs.
In that case you have to provide a pretty strong argument why everyone
should be forced to have a non-volatile log of DDLs.
Conve
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Examining why psql won't do sensible stuff with COPY BINARY, I realized
> that psql still uses PQgetline, which is marked obsolete since 7.4.
> Is this intentional or just a "never reviewed because it works"?
There wasn't any obvious bang for the buck
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I can't find any information of syntax for ANSI Conformance F262, F263. Has
> somebody any information about this points: Extended CASE expression, comma
> separated predicates in simple case expression
There are no such feature IDs listed in either
"Premsun Choltanwanich" <[EMAIL PROTECTED]> writes:
> I think I use contrib/lo type for manage lo. What is wrong?
You need to use the 8.1 version of contrib/lo, not any previous version.
You might find that the easiest way to manage this is to create an empty
database, load the 8.1 contrib/lo de
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Dec 13, 2005 at 11:33:20PM -0500, Tom Lane wrote:
>> and I don't even see the argument for doing it via a table rather
>> than via the postmaster log.
> Simple. Postmaster logs can roll over or otherwise be lost without
> damaging the DB. This w
Andrew Dunstan wrote:
>
> David Fetter wrote:
>
> >I'd much appeciate tips, specific RTFMs and feedback on this so I can
> >get cracking on a patch.
>
> well, before you even start on a patch we should have agreement that
> this is a good idea, and an agreed design.
>
> This is really an m * n
> Ofcourse, this is another can of worms. To do this you would have to be
> able to have the failed query provide hints to the planner telling it
> where it went wrong. Now, it may be possible to provide (via
> post-mortem of an execution) a list of actual selectivites like:
Just being able to pro
David Fetter wrote:
I'd much appeciate tips, specific RTFMs and feedback on this so I can
get cracking on a patch.
well, before you even start on a patch we should have agreement that
this is a good idea, and an agreed design.
This is really an m * n problem. That's what does indeed
Examining why psql won't do sensible stuff with COPY BINARY, I realized
that psql still uses PQgetline, which is marked obsolete since 7.4.
Is this intentional or just a "never reviewed because it works"?
Unfortunately, psql/copy.c also states "if you want to use copy in your
app, this is the co
On Wed, Dec 14, 2005 at 01:52:56AM -0800, David Fetter wrote:
> Folks,
>
> I'm trying to come up with a design for \ commands in psql in 8.2.
> 8.1 broke just about every \ command because they now depend on roles,
> which is great for 8.1 or better, but not so good if you're connecting
> to DBs <
On Tue, Dec 13, 2005 at 12:44:50PM +0800, Christopher Kings-Lynne wrote:
> And the answer is interesting as well:
>
> "I think we have to approach it in two ways. One is that you have to be
> able to execute good plans, and during the execution of a plan you want
> to notice when the actual data
Folks,
I'm trying to come up with a design for \ commands in psql in 8.2.
8.1 broke just about every \ command because they now depend on roles,
which is great for 8.1 or better, but not so good if you're connecting
to DBs <= 8.0. So, I'm volunteering to code up the next version of
psql, which wi
Hello
I can't find any information of syntax for ANSI Conformance F262, F263. Has
somebody any information about this points: Extended CASE expression, comma
separated predicates in simple case expression
Thank You
Pavel Stehule
___
Premsun Choltanwanich wrote:
Dear Richard,
I think I use contrib/lo type for manage lo. What is wrong?
Now I have no idea for manage lo on PostgreSQL 8.1.1, I think I need a time to learn.
Could you give me suggestion?
Go back and check you have ticked the option in the installer. I don'
51 matches
Mail list logo
