Generally, when you read from a set of
subfiles, the OS will cache the reads to some degree, so the disk-seek jitter
is not always that bad. On a highly fragmented disk drive, you might also jump
all over the place reading serially from a single subfile. Of course,
every situation is diffe
On Fri, 23 Sep 2005, Tom Lane wrote:
> postgresql-fe.h defines a ton of stuff that has no business being
> visible to libpq's client applications. It's designed to be used by
> our *own* client-side code (psql and the like), but we have not made
> any attempt to keep it from defining stuff that w
Calculating Optimal memory for disk based sort is based only on minimizing IO.
A previous post stated we can merge as many subfiles as we want in a single pass,
this is not accurate, as we want to eliminate disk seeks also in the merge phase,
also the merging should be done by reading blocks of dat
I sent this from the wrong address last time so it did not go to the list,
I apologize to anyone who may be getting it again...
On Fri, 23 Sep 2005, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > 2) The lo_*64, in order to be convenient from the client end, have
> > functions adde
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Fri, 23 Sep 2005, Tom Lane wrote:
>> Unfortunately that's completely unacceptable from a namespace-pollution
>> point of view.
> I don't quite understand.
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client appl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lee,
> Patricia S.
> Sent: 23 September 2005 17:46
> To: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
> Subject: [HACKERS] PgAdmin3 1.2.2 Install on Win32 Disrupts Pg Service
>
> System: Windows
Thomas Hallgren wrote:
> PL/Java runs a JVM. Since a JVM is multi threaded, PL/Java goes to
> fairly extreme measures to ensure that only one thread at a time can
> access the backend. So far, this have worked well but there is one small
> problem. [...]
I assume this means you have a single loc
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
>
> The real problem here is that int64 isn't a well-defined portable
> datatype, and so it's going to be very hard to export these
> functions in a way that won't break on different platforms,
> a
OK, I have added comments to gram.y to document what is happening.
ALTER ROLE ... ROLE is supported for ALTER GROUP. The others like IN
ROL are supported by CREATE, but when used by ALTER throw an error
printing their internal names, so it is kind of cryptic. Not sure what
we should do to improv
Bruce Momjian writes:
> I see a lot of ALTER ROLE items not documented:
> SYSID
> IN ROLE
> ROLE/USER
> ADMIN
> Is anyone working on documenting these?
No, because they're not actually supported. The grammar happens to
accept them because we use the same productions for
On Fri, Sep 23, 2005 at 04:45:02PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> > > Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
> > > indexes are now restored with the wrong ownership if the user doing
> > > the restore is differ
Added to TODO:
* Simplify dropping roles that have objects in several databases
---
Alvaro Herrera wrote:
> On Fri, Aug 12, 2005 at 09:53:59PM -0400, Bruce Momjian wrote:
> >
> > Can I have a TODO item for this?
Jeremy Drake <[EMAIL PROTECTED]> writes:
> 2) The lo_*64, in order to be convenient from the client end, have
> functions added to libpq as the existing lo_* functions. The client side
> of libpq did not previously know anything about int64 or how to
> send/receive them. I added an include of pos
The cited book also explains how to use a callback function to perform
arbitrary radix sorts (you simply need a method that returns the
[bucketsize] most significant bits for a given data type, for the length
of the key).
So you can sort fairly arbitrary data in linear time (of course if the
key i
Tom Lane wrote:
> Jonathan Beit-Aharon <[EMAIL PROTECTED]> writes:
> > if (!conn)
> >
> > DBLINK_CONN_NOT_AVAIL;
>
> Could we see this in a less broken format?
Here is the patch in text format.
--
Bruce Momjian| http://candle.pha.pa.us
pgman
I see a lot of ALTER ROLE items not documented:
SYSID
IN ROLE
ROLE/USER
ADMIN
Is anyone working on documenting these? I see these flags as used by
and documented in CREATE ROLE too. Should they be disabled for ALTER
ROLE?
---
Jonathan Beit-Aharon <[EMAIL PROTECTED]> writes:
> if (!conn)
>
> DBLINK_CONN_NOT_AVAIL;
> +
> + if (rcon)
> +
> rcon->remoteTrFlag = (PQtransactionStatus(conn) !=
> PQTRANS_IDLE);
>
> - res = PQexec(conn, "BEGIN");
> - if (PQresultStatus(r
For the subfiles, load the top element of each subfile into a priority
queue. Extract the min element and write it to disk. If the next value
is the same, then the queue does not need to be adjusted. If the next
value in the subfile changes, then adjust it.
Then, when the lowest element in the
operations != passes. If you were clever, you could probably write a
modified bubble-sort algorithm that only made 2 passes. A pass is a
disk scan, operations are then performed (hopefully in memory) on what
you read from the disk. So there's no theoretical log N lower-bound on
the number of dis
Yep. Also, bear in mind that the lg(n!)= ~ nlgn - n lower bound on
the number of comparisions:
a= says nothing about the amount of data movement used.
b= only holds for generic comparison based sorting algorithms.
As Knuth says (vol 3, p180), Distribution Counting sorts without
ever comparing ele
From: Simon Riggs <[EMAIL PROTECTED]>
Sent: Sep 23, 2005 5:37 AM
Subject: [PERFORM] Releasing memory during External sorting?
>I have concerns about whether we are overallocating memory for use in
>external sorts. (All code relating to this is in tuplesort.c)
>
A decent external sorting algorithm,
From: Tom Lane <[EMAIL PROTECTED]>
Sent: Sep 23, 2005 2:15 PM
Subject: Re: [PERFORM] Releasing memory during External sorting?
>Mark Lewis <[EMAIL PROTECTED]> writes:
>> operations != passes. If you were clever, you could probably write a
>> modified bubble-sort algorithm that only made 2 passes
Hi,
I'm not a member of this list (yet), so please
CC me on responses and
discussion.
The patch below seems to be completion of work already
started, because the boolean remoteTrFlag was already defined, and all
I had to add was its setting and two references.
I hope someone will find it us
Yep, testing confirms this is fixed. Thanks for the report.
---
Michael Fuhr wrote:
> Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
> indexes are now restored with the wrong ownership if the user doing
>
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
> > indexes are now restored with the wrong ownership if the user doing
> > the restore is different than the user who owned the original index
>
> pg_dump is not the so
Seems this item will have to remain for 8.2. I have added this to TODO:
o Display IN, INOUT, and OUT parameters in \df+
It probably requires psql to output newlines in the proper
column, which is already on the TODO list.
---
On Fri, Sep 23, 2005 at 06:39:35PM +0200, Pailloncy Jean-Gerard wrote:
> >On most platforms it's quite unlikely that any memory would actually
> >get released back to the OS before transaction end, because the
> >memory blocks belonging to the tuplesort context will be intermixed
> >with blocks bel
Mark Lewis <[EMAIL PROTECTED]> writes:
> operations != passes. If you were clever, you could probably write a
> modified bubble-sort algorithm that only made 2 passes. A pass is a
> disk scan, operations are then performed (hopefully in memory) on what
> you read from the disk. So there's no the
This patch implements the ability for large objects to be larger than 2GB.
I believe the limit to now be about 2TB, based on the fact that the large
object page size is 2048 bytes, and the page number is still 32 bits.
There are a few things about this patch which probably require tweaking or
at l
Bruce Momjian writes:
> Tom Lane wrote:
>> Tony Caduto <[EMAIL PROTECTED]> writes:
>>> I just noticed that pronargs in pg_proc does not show the full arg
>>> count, seems only to show count of IN args.
>>> shouldn't this show the full arg count including in/out/inout?
>>
>> There was some discus
Tom Lane wrote:
> Tony Caduto <[EMAIL PROTECTED]> writes:
> > I just noticed that pronargs in pg_proc does not show the full arg
> > count, seems only to show count of IN args.
> > shouldn't this show the full arg count including in/out/inout?
>
> There was some discussion of that just a day or s
Tom Lane wrote:
> Bruce Momjian writes:
> > Yea, we could do that, but does it make sense to downgrade the
> > connection message, especially since the "connection authorized" message
> > doesn't contain the hostname. We would have to add the host name to the
> > "connection authorized" message a
Ron Peacetree <[EMAIL PROTECTED]> writes:
> 2= No optimal external sorting algorithm should use more than 2 passes.
> 3= Optimal external sorting algorithms should use 1 pass if at all possible.
A comparison-based sort must use at least N log N operations, so it
would appear to me that if you have
System: Windows XP Pro SP2
Running Postgres 8.0.3 for several months with the embedded PgAdmin3
1.2.1 on the same machine with no problems. Postgres is configured to
start automatically as a service. I installed the PgAdmin3 1.2.2 which
requested a Windows reboot. I rebooted without stopping Postg
On most platforms it's quite unlikely that any memory would
actually get
released back to the OS before transaction end, because the memory
blocks belonging to the tuplesort context will be intermixed with
blocks
belonging to other contexts. So I think this is pretty pointless.
(If you can't
Paolo Magnoli wrote:
> Hi, I seem to recall that in Oracle you load into specific partitions
> without specifically naming them in insert statements (in other words you
> insert into table, the engine redirects data to the corrisponding
> partition),
This is correct
--
__
Simon Riggs <[EMAIL PROTECTED]> writes:
> Since we know the predicted size of the sort set prior to starting the
> sort node, could we not use that information to allocate memory
> appropriately? i.e. if sort size is predicted to be more than twice the
> size of work_mem, then just move straight to
On Fri, 2005-09-23 at 10:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If not, I would propose that when we move from qsort to tapesort mode we
> > free the larger work_mem setting (if one exists) and allocate only a
> > lower, though still optimal setting for the tapesort
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 23 September 2005 15:48
> To: Dave Page
> Cc: Michael Paesold; Thomas Hallgren; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] What has happened to pgxs?
>
> "Dave Page" writes:
> >> It does? Dave just to
"Dave Page" writes:
>> It does? Dave just told us that the standard installer
>> package is built to install into /usr/local/pgsql.
> No, I said it's built into the installer from /usr/local/pgsql (the path
> in the msys dev environment). It actually installs into C:\Program
> Files\PostgreSQL\
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 23 September 2005 15:24
> To: Michael Paesold
> Cc: Thomas Hallgren; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] What has happened to pgxs?
>
> "Michael Paesold" <[EMAIL
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 23 September 2005 15:16
> To: Dave Page
> Cc: Thomas Hallgren; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pgxs and pginstaller
>
> "Dave Page" writes:
> >> My temporary patch for this was to remove all
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Someone loads a library that contains a method that spawns a new thread.
They already broke the backend when they did that. max_stack_depth is
just the tip of the iceberg.
I knew I'd get a response like that from you :-)
Tom Lane wrote:
"Dave Page" writes:
My temporary patch for this was to remove all lines staring
with 'ifeq'
or 'endif' between line 66 and 102.
I agree with your earlier comment - this should definitely be fixed in
PostgreSQL, not pgInstaller.
It's not broken, and I've
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Bruce, others, could this comparision be made case-insensitive at least, so
> that it at least finds "PostgreSQL" and does not append postgresql in that
> case?
We could certainly add "PostgreSQL" to the set of checked-for strings,
but...
> That w
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Someone loads a library that contains a method that spawns a new thread.
They already broke the backend when they did that. max_stack_depth is
just the tip of the iceberg.
regards, tom lane
---(end of
"Dave Page" writes:
>> My temporary patch for this was to remove all lines staring
>> with 'ifeq'
>> or 'endif' between line 66 and 102.
> I agree with your earlier comment - this should definitely be fixed in
> PostgreSQL, not pgInstaller.
It's not broken, and I've seen no argument as to why
Simon Riggs <[EMAIL PROTECTED]> writes:
> If not, I would propose that when we move from qsort to tapesort mode we
> free the larger work_mem setting (if one exists) and allocate only a
> lower, though still optimal setting for the tapesort. That way the
> memory can be freed for use by other users
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> There's another issue with the Makefile.global.in that I feel should be
> addressed here. The file contains a lot of entries like:
> ifeq "$(findstring pgsql, $(pkgincludedir))" ""
> ifeq "$(findstring postgres, $(pkgincludedir))" ""
> override pkginc
Thomas Hallgren wrote:
Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.
That triggers the append of 'postgresql' on all directories since my
install lo
Hi,
I have a problem with PL/Java that, if it's going to have a good
solution, requires your help.
PL/Java runs a JVM. Since a JVM is multi threaded, PL/Java goes to
fairly extreme measures to ensure that only one thread at a time can
access the backend. So far, this have worked well but the
On Fri, 2005-09-23 at 12:30 +0200, Paolo Magnoli wrote:
> It would be good to have an insert behaviour similar to Oracle by default.
OK, thanks.
> Also I see that the original table is always scanned, partition exclusion
> happens only on the derived tables, is this correct?
Yes, though if you
Hi, I seem to recall that in Oracle you load into specific partitions
without specifically naming them in insert statements (in other words you
insert into table, the engine redirects data to the corrisponding
partition), I quickly looked at postgresql partitioning and it seems to me
that you need
> -Original Message-
> From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
> Sent: 23 September 2005 11:17
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: pgxs and pginstaller
>
> It's two things basically. One I think that the installer
> team can fix,
> the other is I
Dave Page wrote:
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 10:49
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: pgxs and pginstaller
Dave Page wrote:
In the case of PostgreSQL itself, it's built in
/us
How To Hack Or Steal Credit Card Information
HOW TO GAIN VALID CREDIT CARD NUMBERS
In August, 1999, Scientific American ( http://www.sciam.com/ ) has published an article entitled How to stealmillions in chump change which was about online credit card theft. The original article can sti
> -Original Message-
> From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
> Sent: 23 September 2005 10:49
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: pgxs and pginstaller
>
> Dave Page wrote:
> >
> > In the case of PostgreSQL itself, it's built in
> /usr/local/src
On Thu, 2005-09-22 at 14:37 -0500, Jim C. Nasby wrote:
> On Thu, Sep 22, 2005 at 10:11:50AM +0100, Simon Riggs wrote:
> > On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > Is it possible that the Release Notes do not fully explain the
> > > > C
Dave Page wrote:
In the case of PostgreSQL itself, it's built in /usr/local/src/postgresql-8.x,
> installed to /usr/local/pgsql and then packaged up from there.
Perhaps you should build it in the directory that the installer suggests
as default for the installation? That way, most of the ins
I have concerns about whether we are overallocating memory for use in
external sorts. (All code relating to this is in tuplesort.c)
When we begin a sort we allocate (work_mem | maintenance_work_mem) and
attempt to do the sort in memory. If the sort set is too big to fit in
memory we then write to
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 22 September 2005 23:07
> To: Thomas Hallgren
> Cc: pgsql-hackers@postgresql.org
> Subject: [HACKERS] pgxs and pginstaller
>
> > There is other stuff that seems strange to me.
Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.
That triggers the append of 'postgresql' on all directories since my
install location *does not* contain
On Thu, Sep 22, 2005 at 10:05:57PM -0400, Tom Lane wrote:
> With respect to the original point, I'm pretty nervous about either
> accepting or rejecting a performance-oriented patch on the strength
> of a single test case. This report certainly doesn't favor the PCTFREE
> patch, but it probably sh
63 matches
Mail list logo
