On Fri, 2007-12-14 at 19:04 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Where am I going wrong? Are many of these lseeks no-ops or something?
>
> They're not supposed to be, but if you only tracked seeks and not
> reads or writes, it's hard to be sure what's going on.
The
[EMAIL PROTECTED] wrote:
Hello
i have a python script to update 60 rows to one table from a csv file in my
postgres database and it takes me 5 hours to do the transaction...
Let's see if I guessed correctly.
Your Python script is stepping through a 600,000 row file and updating
inform
Hello
i have a python script to update 60 rows to one table from a csv file in my
postgres database and it takes me 5 hours to do the transaction...
I'm on debian etch with 8.1 postgres server on a 64 bits quad bi opteron.
I have desactived all index except the primary key who is not update
Jeff Davis <[EMAIL PROTECTED]> writes:
> Where am I going wrong? Are many of these lseeks no-ops or something?
They're not supposed to be, but if you only tracked seeks and not
reads or writes, it's hard to be sure what's going on.
8.2's VACUUM should process a btree index (this is a btree index
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Why double writes per read, plus massive writes at checkpoint?
The double writes aren't surprising: freezing has to be WAL-logged,
and the odds are that each page hasn't been touched since the last
checkpoint, so the WAL log will include a complete pa
"bigtable" has about 60M records, about 2M of which are dead at the time
of VACUUM. Shared_buffers are about 1GB, and the machine has 4GB of
memory.
If I run a "SELECT COUNT(*) FROM bigtable", and I ktrace that (FreeBSD)
for 10 seconds, I see only a handful of lseek calls (33), which is no
surpris
Roberts, Jon escribió:
> I'm not familiar at all with pg_read_file. Is it wide open so a user can
> read any file they want? Can you not lock it down like utl_file and
> directories in Oracle?
That function is restricted to superusers.
--
Alvaro Herrera Developer, http
On Dec 14, 2007 4:24 PM, Andreas Kretschmer <[EMAIL PROTECTED]> wrote:
> Some days ago i have seen a pl/pgsql- code - obfuscator, iirc somewhere
> under http://www.pgsql.cz/index.php/PostgreSQL, but i don't know how it
> works, and i can't find the correkt link now, i'm sorry...
I started one awhi
I'm not familiar at all with pg_read_file. Is it wide open so a user can
read any file they want? Can you not lock it down like utl_file and
directories in Oracle?
Jon
> -Original Message-
> From: Jonah H. Harris [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 14, 2007 3:04 PM
> To:
Roberts, Jon <[EMAIL PROTECTED]> schrieb:
> Is it possible yet in PostgreSQL to hide the source code of functions from
> users based on role membership? I would like to avoid converting the code
> to C to secure the source code and I don't want it obfuscated either.
Some days ago i have seen a
On Dec 14, 2007 2:03 PM, Bill Moran <[EMAIL PROTECTED]> wrote:
> I disagree here. If they're connecting remotely to PG, they have no
> direct access to the disk.
pg_read_file?
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax: 732.331
On Fri, 2007-12-14 at 11:29 -0800, Jeff Davis wrote:
> "bigtable" has about 60M records, about 2M of which are dead at the time
> of VACUUM. Shared_buffers are about 1GB, and the machine has 4GB of
> memory.
Forgot to mention: version 8.2.4
Regards,
Jeff Davis
--
In response to "Joshua D. Drake" <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 14 Dec 2007 11:18:49 -0500
> Bill Moran <[EMAIL PROTECTED]> wrote:
>
> > > That is like saying anyone that has rights to call a web service
> > > should be able to see the source c
Joshua D. Drake wrote:
> > > However, in the current configuration, all users with permission to
> > > log in can see all source code. They don't have rights to execute
> > > the functions but they can see the source code for them. Shouldn't
> > > I be able to revoke both the ability to execute
I'm grooming a new server to replace one that is soon to be retired.
Most of the data was loaded very close together, in terms of
database transaction numbers, and probably 95% of it will never be
updated. To assess the potential impact of a "freeze everything in
the database at once" sort of nigh
PostgreSQL: 8.2
My understanding is that when one creates a large object there is no way
to link the large object to a field in a table so that cascading delete
can occur. Is this correct? My understanding is that you have to
manually delete the large object.
I also read something about t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Dec 2007 11:18:49 -0500
Bill Moran <[EMAIL PROTECTED]> wrote:
> > That is like saying anyone that has rights to call a web service
> > should be able to see the source code for it.
>
> I think that's a good idea. If vendors were forced pu
On Fri, 14 Dec 2007, Tom Lane wrote:
> Matthew <[EMAIL PROTECTED]> writes:
> > Interesting thread. Now, I know absolutely nothing about how the data is
> > stored, but it strikes me as being non-optimal that every single block on
> > the disc needs to be written again just to update some hint bits.
Matthew <[EMAIL PROTECTED]> writes:
> Interesting thread. Now, I know absolutely nothing about how the data is
> stored, but it strikes me as being non-optimal that every single block on
> the disc needs to be written again just to update some hint bits. Could
> those bits be taken out into a separ
In response to "Roberts, Jon" <[EMAIL PROTECTED]>:
> > > In an ideal world, if a user can't modify a function, he/she shouldn't
> > be
> > > able to see the source code. If the user can execute the function, then
> > the
> > > user should be able to see the signature of the function but not the
>
>>> On Thu, Dec 13, 2007 at 3:40 PM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-12-13 at 15:19 -0600, Kevin Grittner wrote:
>> So one would expect a write-intensive initial vacuum after a
>> PITR-style recovery?
> An interesting issue when running wi
On Thu, 13 Dec 2007, Simon Riggs wrote:
> On Thu, 2007-12-13 at 09:46 -0600, Kevin Grittner wrote:
> > Even though there have been no rollbacks, updates, or deletes on this
> > table, the vacuum is writing as much as it is reading while dealing
> > with the TOAST data.
>
> Writing hint bits. Annoyi
> > In an ideal world, if a user can't modify a function, he/she shouldn't
> be
> > able to see the source code. If the user can execute the function, then
> the
> > user should be able to see the signature of the function but not the
> body.
>
> I doubt that's going to happen. Mainly because I
In response to "Roberts, Jon" <[EMAIL PROTECTED]>:
> Is it possible yet in PostgreSQL to hide the source code of functions from
> users based on role membership? I would like to avoid converting the code
> to C to secure the source code and I don't want it obfuscated either.
>
> In an ideal wo
>>> On Fri, Dec 14, 2007 at 1:42 AM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> My feeling is that vacuum's purpose in life is to offload maintenance
> cycles from foreground queries, so we should be happy to have it setting
> all the hint bits.
Absolutely.
> If K
Is it possible yet in PostgreSQL to hide the source code of functions from
users based on role membership? I would like to avoid converting the code
to C to secure the source code and I don't want it obfuscated either.
In an ideal world, if a user can't modify a function, he/she shouldn't be
ab
Matthew Lunnon wrote:
Ah I was afraid of that. Maybe I'll have to come out of the dark ages.
At the very least, upgrade to latest 7.4 minor version. It probably
won't help with you're performance, but 7.4.3 is very old. There's been
a *lot* of bug fixes between 7.4.3 and 7.4.18, including fi
Bebarta, Simanchala wrote:
I am doing a performance benchmarking test by using benchmarkSQL tool on
postgresql 8.2.4.I need to tune the parameters to achieve an optimal
performance of the postgresql database.
I have installed postgresql 8.2.4 on RHEL AS4. It is a DELL Optiplex
GX620 PC with 4GB
28 matches
Mail list logo
