At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
>This is an interesting point, that an index scan may fit in the cache
>while a sequential scan may not. I can see cases where even a index
>scan of a large percentage of the table may win over an sequential scan.
>Interesting.
Yes and if it fits
At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>And how about getting database internals via SQL-functions - e.g. getting
>BLCSIZE, LOBBLCSIZE?
ISTM that there would be some merit in making a selection of compile-time
options available via SQL. Is this worth considering?
---
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 1 - All SETs are rolled back in aborted transaction
> > 2 - SETs are ignored after transaction abort
> > 3 - All SETs are honored in aborted transaction
> > ? - Have SETs vary in behavior depending on variabl
Neil Conway <[EMAIL PROTECTED]> writes:
> ...Based on that data, I'd vote against making any changes to NAMEDATALEN.
It looked to me like the cost for going to NAMEDATALEN = 64 would be
reasonable. Based on these numbers I'd have a problem with 128 or more.
But as you observe, pgbench numbers a
This patch does not compile correctly:
pg_backup_archiver.c: In function `ahwrite':
pg_backup_archiver.c:1252: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1259: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1263: warning: pointer of type `
I also want to implement the same feature but for
ecpg. On INFORMIX there is the following syntax to control
timeouts:
SET LOCK MODE TO [WAIT [seconds] | NO
WAIT]
There is 2 possibilities:
- either the pre-processor implements execution of
the statement with the asynchronous functions. T
On Tue, 23 Apr 2002, mlw wrote:
> > On a system that has neither read-ahead nor sorting of I/O requests,
> > yes. Which systems are you using that provide neither of these
> > facilities?
>
> This only happens if the OS can organize the I/O requests in such a manner. It
> is a non-trivial functio
> Haven't several people observed that the results from pgbench are
> very inconsistent? Perhaps some results from OSDB would be
worthwhile...
I've not looked very hard at OSDB. But it doesn't seem to run out of
the box.
> Based on that data, I'd vote against making any changes to
NAMEDATALEN.
Curt Sampson wrote:
>
> On Thu, 18 Apr 2002, Michael Loftis wrote:
>
> > mlw wrote:
> >
> > >The supposed advantage of a sequential read over an random read, in
> > >an active multitasking system, is a myth. If you are executing one
> > >query and the system is doing only that query, you may be
Lincoln Yeoh wrote:
>
> At 10:48 AM 4/18/02 -0400, mlw wrote:
> >Bruce Momjian wrote:
> > >
> > > Have you tried reducing 'random_page_cost' in postgresql.conf. That
> > > should solve most of your problems if you would like more index scans.
> >
> >My random page cost is 1 :-)
>
> What happens
On 23 Apr 2002 23:36:14 -0300
"Rod Taylor" <[EMAIL PROTECTED]> wrote:
> First is on pgbench -i (-s 5)
> Second is on pgbench -t 3000 -s 5
Haven't several people observed that the results from pgbench are
very inconsistent? Perhaps some results from OSDB would be worthwhile...
> The first test on
Each test set has 3 time sets.
First is on pgbench -i (-s 5)
Second is on pgbench -t 3000 -s 5
Third is on postmaster during the run of the first 2.
The first test on a slow harddrive has a large effect for increasing the
namedatalen length.
Second through 4th sets don't really show any issue
Patch applied. Thanks.
---
Mario Weilguni wrote:
> Am Donnerstag, 11. April 2002 17:44 schrieb Tom Lane:
> > "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > > And I did not find out how I can detect the large object
> >
Updated version applied. Thanks.
---
Nicolas Bazin wrote:
> Sorry for the package, but the following patch need to be applied to get the new
>verion compiled on SCO Openserver 5.0.5 and Unixware 7.1.1
[ Attachment, ski
Patch applied. Thanks.
---
Ulrich Neumann wrote:
> Hello everybody,
>
> If possible please add the following patch to better support NetWare.
>
> best regards
>
> Ulrich Neumann
> Novell Worldwide Developer Support
>
Bruce Momjian writes:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > Based on this report, I am adding a FUNC_MAX_ARGS define to
> > > src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
> > > there, we should have FUNC_MAX_ARGS too.
> >
> > We probably shouldn't
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Based on this report, I am adding a FUNC_MAX_ARGS define to
> > src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
> > there, we should have FUNC_MAX_ARGS too.
>
> We probably shouldn't have either one in there.
I thought
Bruce Momjian writes:
> Based on this report, I am adding a FUNC_MAX_ARGS define to
> src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
> there, we should have FUNC_MAX_ARGS too.
We probably shouldn't have either one in there.
--
Peter Eisentraut [EMAIL PROTECTED]
Michael Loftis wrote:
> The benchmarks will depend mostly on the depth of the Btree. Hashes
> will be markedly faster only in the case(s) where descending into the
> tree to produce a matching leaf node would take longer than walking to
> the appropriate item in a hash.
>
> Most of the time
Based on this report, I am adding a FUNC_MAX_ARGS define to
src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
there, we should have FUNC_MAX_ARGS too.
---
Chris Ryan wrote:
> Bruce,
>
> I'm not a
Thomas Lockhart writes:
> I'd like to implement *something* to help us collect information on what
> platforms actually have what features. This would be useful, for
> example, for figuring out whether any platforms are lacking 8 byte
> integers or are missing timezone infrastructure.
I don't th
Nicolas Bazin wrote:
> I read a thread about table lock timeout but don't know whether
> anything has been done about it.
>
> Here is what I'd like to do: I don't want my transactions to
> be on hold for too long so I'd like to use a syntax I use on
> INFORMIX already: SET LOCK MODE TO [WAIT [s
On Tue, 2002-04-23 at 12:52, Martijn van Oosterhout wrote:
> Well, from my thinking about how you would use these fields in a logical
> way, it seems it's possible for xmax to be non-zero if the transaction
> numbered xmax was not committed. But in that case (unless it was a delete)
> there would
Tom Lane wrote:
> Michael Loftis <[EMAIL PROTECTED]> writes:
> > IE I'd like to have the information come back as say a notice or maybe
> > as extra information for an EXPLAIN for my purposes, but unless there is
> > interest, consensus on how it should be done, and a TODO item made of
> > it,
Hi!
I checked out the StringInfo functions, they are basicly the same as the
Chunks functions I use, but I'll use the others instead even thought I don't
think they will help me on my problem. But anyway, I've checked out the malloc
and realloc function, and believe that they won't allow alloc
Bruce Momjian wrote:
> OK, would people please vote on how to handle SET in an aborted
> transaction? This vote will allow us to resolve the issue and move
> forward if needed.
>
> In the case of:
>
> SET x=1;
> BEGIN;
> SET x=2;
> query_that_aborts_transaction;
>
On Tuesday 23 April 2002 04:27 pm, Bruce Momjian wrote:
> OK, would people please vote on how to handle SET in an aborted
> transaction? This vote will allow us to resolve the issue and move
> forward if needed.
> at the end, should 'x' equal:
> 1 - All SETs are rolled back in aborted tra
Michael Meskes wrote:
> As some may know I will be talking about PostgreSQL on LinuxTag (6th of
> June - 9th of June) in Karlsruhe, Germany. In particular I want to
> address:
>
> - The functionality of PostgreSQL
> - Its stability and capability of handling large databases, ideally by
> some c
Discription of patch for python.
---
Andrew Johnson wrote:
> On Wed, Apr 17, 2002 at 10:12:10PM -0400, Bruce Momjian wrote:
> >
> > No one has replied, so I worked up a patch that I will apply in a few
> > days. Let me k
Andreas Scherbaum wrote:
> Tom Lane wrote:
> >
> > Andreas Scherbaum <[EMAIL PROTECTED]> writes:
> > > On the other hand, i copied some parts from contrib/noupdate (there'e no
> > > licence in the readme) and now i think, this is contributed under BSD
> > > licence.
> > > I'm sure or i'm wrong? I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 1 - All SETs are rolled back in aborted transaction
> 2 - SETs are ignored after transaction abort
> 3 - All SETs are honored in aborted transaction
> ? - Have SETs vary in behavior depending on variable
My vote is 1 - roll back
1
SET should follow transaction semantics and rollback.
Jan
Bruce Momjian wrote:
> OK, would people please vote on how to handle SET in an aborted
> transaction? This vote will allow us to resolve the issue and move
> forward if needed.
>
> In the case of:
>
> SET x=1;
>
Tatsuo Ishii wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > In my understanding we are going to turn on the --enable-syslog
> > > *configure* option by default (or remove the configuration option
> > > completely), but not change the syslog option in postgresql.conf
> > > (currently def
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > http://archives.postgresql.org/pgsql-general/2001-09/msg00234.php
> > Nobody opposed to the idea of name ordering in that thread.
>
> Okay, I've committed the fixes that implement this.
>
> > But note that this is on TODO:
> > * Al
Bradley McLean wrote:
> * Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
> >
> > 1 - All SETs are rolled back in aborted transaction
> > 2 - SETs are ignored after transaction abort
> > 3 - All SETs are honored in aborted transaction
> > ? - Have SETs vary in behavior depen
* Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
>
> 1 - All SETs are rolled back in aborted transaction
> 2 - SETs are ignored after transaction abort
> 3 - All SETs are honored in aborted transaction
> ? - Have SETs vary in behavior depending on variable
>
> Ou
Luis Alberto Amigo Navarro wrote:
> Hi All.
> I've been reading all the thread and I want to add a few points:
>
> You can set enable_seqscan=off in small or easy queries, but in large
> queries index can speed parts of the query and slow other, so I think it is
> neccesary if you want Postgres t
Lincoln Yeoh wrote:
> At 10:48 AM 4/18/02 -0400, mlw wrote:
> >Bruce Momjian wrote:
> > >
> > > Have you tried reducing 'random_page_cost' in postgresql.conf. That
> > > should solve most of your problems if you would like more index scans.
> >
> >My random page cost is 1 :-)
>
> What happens wh
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
SET x=3;
COMMIT;
at the
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I was thinking about something like "make report" which would mail the
> results of ./configure to, say, the ports mailing list. We could mention
> it in the text message printed at the end of the make cycle.
I think it'd be a bad idea to encourage pe
Steffen Nielsen <[EMAIL PROTECTED]> writes:
> I have tried using chunks technique when creating huge string for a stored
> procedure (C code). I work like charm for small string, but when i create
> large strings i get a "server closed the connection unexpectedly" :-(
Look for bugs in your code
I have tried using chunks technique when creating huge string for a stored
procedure (C code). I work like charm for small string, but when i create
large strings i get a "server closed the connection unexpectedly" :-( I use
palloc and repalloc for memory handling. Note! I made a standard C pro
On Tue, 23 Apr 2002, Martijn van Oosterhout wrote:
> > But I think the most useful behaviour should be to dump system fields
> > too, so mildly knowledgeable sysadmin can import the dump and do the
> > right thing afterwards (like restore data as it was before transaction
> > nr 7000)
>
> Well, i
On Tue, 23 Apr 2002 [EMAIL PROTECTED] wrote:
> Suggestion: Why not embed this information into the binary, and
> provide some way of extracting it.
I like this!
> [Downside: "Announcement, script kiddies: If you find option
> UPDATE_DESCR_TABS=1 in the configuration information, then there's a
On Tue, Apr 23, 2002 at 09:15:22AM +0200, Hannu Krosing wrote:
> On Tue, 2002-04-23 at 01:29, Martijn van Oosterhout wrote:
> >
> > The dumping is more of an extra, the original idea was to check for errors
> > in the datafiles. Hence the working name of "pgfsck". At the moment the
> > dumping du
> -Original Message-
> From: Francisco Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 22 April 2002 22:35
> To: [EMAIL PROTECTED]
> Subject: Re: Implement a .NET Data
>
>
>
>
> Thanks Jean.
>
> I will send a message to the ODBC list.
> At least I didn't create the project in sourcefo
46 matches
Mail list logo
