>Robert Treat
> On Sunday 15 February 2004 16:36, Tom Lane wrote:
> > Anthony Rich <[EMAIL PROTECTED]> writes:
> > > When one process has a "row lock" on one or more rows
> > > in a table, using "SELECT...FOR UPDATE" in default lock
> > > mode, another process has NO WAY of aborting from the
> > >
Yes, surely, unless someone wants to argue for reverting that change
to pg_atoi. I can't see a reason for having them act inconsistently.
While we are at it we should make sure these functions are all on the
same page about allowing leading/trailing whitespace. I seem to recall
that the spec says
Neil Conway <[EMAIL PROTECTED]> writes:
> Chris KL recently pointed out to me that we currently don't raise an
> error when attempting to cast a zero-length string to a float:
> Whereas int and numeric reject zero-length strings:
> So, should we fix oid and float?
Yes, surely, unless someone want
Christopher Kings-Lynne wrote:
> > Parsing is a whole nother ball of wax besides lexing. I wasn't planning
> > to put *that* into psql. Remember the only thing psql really wants from
> > this is to detect where end-of-statement is ...
>
> Forgive my lameness, but I've never truly figured out whe
Patch applied. Thanks.
I modified the doc wording a bit --- patch attached.
---
Andrew Dunstan wrote:
>
> You can find it here.
>
> http://archives.postgresql.org/pgsql-patches/2004-02/msg00072.php
>
> I know Neil was
Chris KL recently pointed out to me that we currently don't raise an
error when attempting to cast a zero-length string to a float:
nconway=# select ''::float8;
float8
0
(1 row)
nconway=# select ''::float4;
float4
0
(1 row)
Similarly for oid:
nconway=# select '':
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am a little concerned about adding the overhead of lex to psql. Right
> > now, some folks have reported that lex/yacc take a considerable amount
> > of processing time in the backend as part of a query, and adding that to
> > psql j
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Parsing is a whole nother ball of wax besides lexing.
> Forgive my lameness, but I've never truly figured out where parsing ends
> and lexing begins. Anyone care to illuminate me on the difference?
The theoretical answer is that you can do
Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only thing psql really wants from
this is to detect where end-of-statement is ...
Forgive my lameness, but I've never truly figured out where parsing ends
and lexing begins. Anyone care
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> You know what would be really sweet? If the lexing was made available
> as a public function. eg. So I could parse queries in phpPgAdmin before
> sending them to the backend, etc...
Parsing is a whole nother ball of wax besides lexing. I w
Actually, I thought the way to handle it would be to duplicate the
backend lexer as nearly as possible. Most of the productions would have
empty bodies probably, but doing it that way would guarantee that in
fact psql and the backend would lex a string the same way, which is
exactly the problem we
>Rod Taylor
> On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > The real question is why does DROP INDEX take more than a couple
of
> > > seconds to complete? It is not held up by locked.
> >
> > AFAICS it shouldn't take any time to complete. I think you
>Kenneth Marshall would like me to post this:
> I agree that in order to manage today's large memory machines, we
> need to have less contention in our buffer management strategies.
> The two main main choke points are in the buffer hash table routines
> and in the buffer management linked lists. U
On 16 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> It looks like we have indexes on all of the date columns except
>> l_commitdate, which appears to be in Q4.
>
>> So I think I'll run against the CVS tip as is, again with an index on
>> l_commitdate, and then another test to confirm your th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 16 Feb 2004, John Li wrote:
> I just implemented eRServer for one of my clients and found many problems
> with it.
TDMSoft has patched eRServer a bit:
http://www.tdmsoft.com/tr/PostgreSQL/download/
Maybe these could help to solve your
Does anybody think there might be some interest in an ISAM driver for
PostgreSQL? I've written a functional alpha that allows PostgreSQL to
be a drop in (or as easy as reasonably possible) replacement for an ISAM
file system driving a COBOL application. It is a STL based thin wrapper
around libpq
John Li wrote:
> I just implemented eRServer for one of my clients and found many
> problems with it.
We do not maintain erserver. You need to talk to the people that you
got it from, for example here:
http://gborg.postgresql.org/project/erserver/projdisplay.php
---(en
[EMAIL PROTECTED] writes:
> It looks like we have indexes on all of the date columns except
> l_commitdate, which appears to be in Q4.
> So I think I'll run against the CVS tip as is, again with an index on
> l_commitdate, and then another test to confirm your theory. Sound good?
Sure, it's only
Rod Taylor <[EMAIL PROTECTED]> writes:
> I not convinced it is waiting on a lock. The queries on that table are
> very short (couple of milliseconds) -- but there are a ton of them. All
> backends appear to be idle (pg_stat_activity with command shown) when we
> start the drop and shortly after hug
Based on my experience, "drop index" is waiting for a chance to place the
lock. If all those queries are within the same connection, "drop index" has
to wait until that connection disconnected.
John Li
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rod Tayl
On 16 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I ran a test with the CAST you recommended for Q4 over the weekend:
>> http://developer.osdl.org/markw/dbt3-pgsql/68/
>> But it didn't seem to have much of an affect on Q4, compared to run
>> #66. I'll still give the CVS tip a try.
>
On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > The real question is why does DROP INDEX take more than a couple of
> > seconds to complete? It is not held up by locked.
>
> AFAICS it shouldn't take any time to complete. I think you're mistaken
> and it i
I just implemented eRServer for one of my clients and found many
problems with it.
It
crashes when using “ers_addtable” to add big tables. The problem is that
it used pg_dump –d then tried to read the whole output in memory. I fixed
it by reading one row at a time and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'd be surprised if using a flex lexer instead made a huge speed
> difference, but maybe I'm wrong.
No, I agree --- it's unlikely to make very much difference in the real
world. Maybe on huge query strings you could notice the difference.
> I'm more
Rod Taylor <[EMAIL PROTECTED]> writes:
> The real question is why does DROP INDEX take more than a couple of
> seconds to complete? It is not held up by locked.
AFAICS it shouldn't take any time to complete. I think you're mistaken
and it is blocking on a lock (it will want exclusive lock on the
[EMAIL PROTECTED] writes:
> I ran a test with the CAST you recommended for Q4 over the weekend:
> http://developer.osdl.org/markw/dbt3-pgsql/68/
> But it didn't seem to have much of an affect on Q4, compared to run
> #66. I'll still give the CVS tip a try.
Hm. Disappointing. I can see fro
I have an IO congested database (PostgreSQL 7.2) with too many
(overlapping) indexes, so the obvious solution is to drop them.
DROP INDEX seems to want to take several minutes to complete, which
causes a backup of clients and me to eventually abort the process to let
all the backed up queries go t
On 15 Feb, Tom Lane wrote:
> I wrote:
>> I see what is going on to make Q4 slow, too. It's this:
>> where o_orderdate >= date '1995-04-01' and o_orderdate < date '1995-04-01' +
>> interval '3 month'
>> ...
>> As of CVS tip the issue could be eliminated by introducing
>> cross-data-type comparis
Robert Treat <[EMAIL PROTECTED]> writes:
> On Sunday 15 February 2004 16:36, Tom Lane wrote:
>> Not so. See the statement_timeout parameter.
> what is needed i think is a lock_timeout, which times out soley for
> cases where the lock can not be aquired in a speedy manner.
I didn't say that there
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
No, it won't. The problem is that it should, because the backend will
see that as '42' followed by a $foo$ quote start.
Ok, I see what you are saying. This mismatch would only happen on
invalid input
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am a little concerned about adding the overhead of lex to psql. Right
> now, some folks have reported that lex/yacc take a considerable amount
> of processing time in the backend as part of a query, and adding that to
> psql just to do $$ seems questio
[EMAIL PROTECTED] wrote:
On 12 Feb, Tom Lane wrote:
http://developer.osdl.org/markw/dbt3-pgsql/62/
This run changes default_statistics_target to 1000 and I have p_partkey,
l_partkey, ps_suppkey, and l_suppkey pg_stats here at 1 min intervals
http (no links on the web page.) Pretty significant
On 16 Feb, Dennis Haney wrote:
> [EMAIL PROTECTED] wrote:
>
>>On 12 Feb, Tom Lane wrote:
>>
>>
>>http://developer.osdl.org/markw/dbt3-pgsql/62/
>>
>>This run changes default_statistics_target to 1000 and I have p_partkey,
>>l_partkey, ps_suppkey, and l_suppkey pg_stats here at 1 min intervals
>>
On Sunday 15 February 2004 16:36, Tom Lane wrote:
> Anthony Rich <[EMAIL PROTECTED]> writes:
> > When one process has a "row lock" on one or more rows
> > in a table, using "SELECT...FOR UPDATE" in default lock
> > mode, another process has NO WAY of aborting from the
> > same request, and reportin
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> No, it won't. The problem is that it should, because the backend will
> >> see that as '42' followed by a $foo$ quote start.
>
> > Ok, I see what you are saying. This mismatch would only happen on
> > invalid input, though. I beli
Tom Lane wrote:
> The best idea I've heard so far is the one about sync() followed by
> a bunch of fsync()s. That seems to be correct, efficient, and dependent
> only on very-long-established Unix semantics.
Agreed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL P
Joe Conway wrote:
Mark Gibson wrote:
I've found the problem, although I'm still a bit confused by it.
I hate to do this to you now, but after some thought I think I have a
better approach -- I'd be interested in opinions on that assessment.
The attached eliminates pgresultGetTupleDesc() en
Christopher Kings-Lynne wrote:
Hey Teodor,
How's this going?
I think you were looking at the same paper I was reading about GiST
indexes. I found the GiST source code somewhat over my head, however.
I hope you'll still working on it and haven't given up!
I hoped begining of year will be qu
38 matches
Mail list logo
