Greg Stark <[EMAIL PROTECTED]> writes:
> Incidentally, "HashAggregate"?! Based on the earlier discussion on this I
> would have expected that line to read "Materialize"
It's using a grouped aggregation node to implement a UNIQUE filter, so
that it can replace the "WHERE foo IN (subselect)" by a st
Thomas Schoebel-Theuer <[EMAIL PROTECTED]> writes:
> I instrumented the file backend/storage/lmgr/lock.c with printf() statements
> in order to find out the locking behaviour of typical applications using
> locking.
> When I later analyzed the logfiles produced that way, I found a very strange
> b
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Early performance tests on my laptop suggest it's about 8% faster for
> writing when both the FS and PostgreSQL use 16K blocks.
BTW, I don't really believe that one set of tests, conducted on one
single machine, are anywhere near enough justification f
On Thu, 28 Aug 2003, Marc G. Fournier wrote:
>
>
> On Thu, 28 Aug 2003, Thomas Swan wrote:
>
> > Has anyone looked at changing the default block size across the board
> > and what the performance improvements/penalties might be? Hardware has
> > changed quite a bit over the years.
>
> I *thin
Tom Lane wrote:
>Thomas Swan <[EMAIL PROTECTED]> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>I'm a little uncomfortable with introducing a cross-platform variation
>>>in the standard block size.
>>>
>>>
>>>
>>Has anyone looked at changing the default block size across the board
>>and what t
On Thu, Aug 28, 2003 at 03:56:18PM -0400, Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Hrm, well, given things just went to beta2, I'm going to bump
> > postgresql-devel to beta2 and include this patch for now, however, I'm
> > going to explicitly requests that people who have
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I have no objection to removing it now, but previously I think you
agreed with Bruce's comment that we should leave it intact (but
deprecated) for 7.4, and remove in 7.5.
Did we discuss this already? I'd forgotten.
In any case, the module
On Thu, 28 Aug 2003, Thomas Swan wrote:
> Has anyone looked at changing the default block size across the board
> and what the performance improvements/penalties might be? Hardware has
> changed quite a bit over the years.
I *think* that the reason for the performance improvement on FreeBSD is
> > Hrm, well, given things just went to beta2, I'm going to bump
> > postgresql-devel to beta2 and include this patch for now, however,
> > I'm going to explicitly requests that people who have problems or
> > successes with beta2 on FreeBSD ask me before possible reporting
> > problems with a pla
Greg Stark <[EMAIL PROTECTED]> writes:
> Hmmm I think there's still something missing here. I was using pg_restore -r
> (actually I was using -L but the list was originally generated with -r) which
> seemed like a good idea at the time. Rereading it now it seems like it
> shouldn't change anything
Tom Lane <[EMAIL PROTECTED]> writes:
> AFAICT the difference is not whether you create the FK constraint during
> table creation or add it later (in fact, the same code is executed
> either way). The difference in Greg's example is that he said
> "REFERENCES test" in one case and "REFERENCES tes
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Hrm, well, given things just went to beta2, I'm going to bump
> postgresql-devel to beta2 and include this patch for now, however, I'm
> going to explicitly requests that people who have problems or
> successes with beta2 on FreeBSD ask me before possib
> Greg Stark <[EMAIL PROTECTED]> writes:
>> Hmmm I think there's still something missing here. I was using pg_restore -r
>> (actually I was using -L but the list was originally generated with -r) which
>> seemed like a good idea at the time. Rereading it now it seems like it
>> shouldn't change any
Tom Lane wrote:
>Sean Chittenden <[EMAIL PROTECTED]> writes:
>
>
>>Are there any objections
>>to me increasing the block size for FreeBSD installations to 16K for
>>the upcoming 7.4 release?
>>
>>
>
>I'm a little uncomfortable with introducing a cross-platform variation
>in the standard bloc
> See:
> http://developer.postgresql.org/docs/postgres/functions-comparisons.html#AEN12154
>
> regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM pg_shadow
> s, pg_group g WHERE s.usesysid = any (g.grolist);
These forms below are all equivalent, right?
If so ideally they w
On Thu, Aug 28, 2003 at 02:11:26PM -0700, Jenny - wrote:
> hi ,
> iam trying to run gdb on postgresql to stack-trace the functions that get
> called when a lock is taken.
> >gdb *program*
> what do i pass in place of program inorder to run gdb on postgresqql
After the backend is running, get its
Hello:
I'm developing a TLS library in C# for my PostgreSQL ADO.NET Data
Provider, i can work well using the openssl test server, using:
openssl s_server -accept 443 -key server.key -cert server.crt -tls1 -bugs
But when i try to use it for connect to postgresql (7.4 on
Windows+Cygwin) i get al
Hi,
I'm doing research on locking pattern of applications. I chose PostgreSQL
7.3.3 as an example application due to availability of sourcecode.
I instrumented the file backend/storage/lmgr/lock.c with printf() statements
in order to find out the locking behaviour of typical applications using
lo
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> If I'm reading this right, this bug means you could do:
> select * from table where field in (1,2,3,4)
> where you should get say 100 rows, and you might not get all 100 rows?
Yes, if you were concurrently inserting into the same table. The given
exam
There's been some recent discussion on some of the FreeBSD mailing
lists about PostgreSQL and performance. FreeBSD uses 16K blocks for
its FS and it has been suggested that PostgreSQL on FreeBSD be
modified to use 16K blocks instead of 8K blocks. Are there any
adverse reactions or reasons to not
Joe Conway kirjutas N, 28.08.2003 kell 21:15:
> Greg Stark wrote:
> > Specifically I want to know how to replace my int_array_aggregate(int) and
> > int_array_enum(_int) calls.
>
> I have no idea what those are -- are they from contrib?
>
> You can create an aggregate to turn arbitrary datatype e
On Thu, 28 Aug 2003, Tom Lane wrote:
> I've traced through the failure reported here by Markus Kräutner:
> http://archives.postgresql.org/pgsql-hackers/2003-08/msg01132.php
>
> What is happening is that as the UPDATE adds tuples (all with the same
> hash key value) to the table, the hash bucket b
> > Are there any objections to me increasing the block size for
> > FreeBSD installations to 16K for the upcoming 7.4 release?
>
> I'm a little uncomfortable with introducing a cross-platform
> variation in the standard block size. That would have implications
> for things like whether a table d
hi ,
iam trying to run gdb on postgresql to stack-trace the functions that get
called when a lock is taken.
gdb *program*
what do i pass in place of program inorder to run gdb on postgresqql
thanks
jenny
_
Get MSN 8 and help protect
Hannu Krosing wrote:
Any idea of performance - is this array_aggregate(anyelement) faster,
slower or about same than int_array_aggregate(int) ?
I haven't tested, but I'd guess for an array of any significant length
int_array_aggregate() is faster (see my other post). That's one of the
reasons I h
Joe Conway <[EMAIL PROTECTED]> writes:
> I have no objection to removing it now, but previously I think you
> agreed with Bruce's comment that we should leave it intact (but
> deprecated) for 7.4, and remove in 7.5.
Did we discuss this already? I'd forgotten.
In any case, the module isn't visi
Tom Lane wrote:
What I'm thinking of doing is removing the code, and replacing the
README with a note explaining how to convert contrib/array queries to
use the new mainstream syntaxes. That will give contrib/array users
a clue what they're supposed to do. In a release or three the README
could g
Thomas Swan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm a little uncomfortable with introducing a cross-platform variation
>> in the standard block size.
>>
> Has anyone looked at changing the default block size across the board
> and what the performance improvements/penalties might be?
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> You do realize that you'll be forcing initdbs on people if you
>> blithely add and remove such a patch?
> Yup. I was tempted to include another patch just to bump the catalog
> version in the event that it doesn't gracefully detect differing block
>
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Are there any objections
> to me increasing the block size for FreeBSD installations to 16K for
> the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That would have implications
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
How much of that is already replaceable by the tactic of using
quote_literal() wherever possible? It's safest to
looking into it ... thanks
On Thu, 28 Aug 2003, Matthew T. O'Connor wrote:
> Hey, I just tried to to a search of the mail archives and got an error.
> I was trying to go here:
>
> http://archives.postgresql.org/search.php?q=autovacuum&ps=50&wm=wrd&o=0&ul=http%3A%2F%2Farchives.postgresql.org%2Fpg
This is a spill over from some discussions on some of the FreeBSD
mailing lists about FS performance. After FreeBSD 4.5-RELEASE, the
file system block size was bumped from 8K to 16K. Right now,
PostgreSQL still stores data in 8K blocks. Are there any objections
to me increasing the block size fo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What is the state of things regarding having to use massive strings of
> quotes like this (taken from the 7.3 docs)?:
How much of that is already replaceable by the tactic of using
quote_literal() wherever possible? It's safest to be using
quote_liter
Joe Conway <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>> And how to replace my "arr *= n" calls too.
> See:
> http://developer.postgresql.org/docs/postgres/functions-comparisons.html#AEN12154
That reminds me --- contrib/array is definitely obsolete now, and there
may be parts of the other c
Hey, I just tried to to a search of the mail archives and got an error.
I was trying to go here:
http://archives.postgresql.org/search.php?q=autovacuum&ps=50&wm=wrd&o=0&ul=http%3A%2F%2Farchives.postgresql.org%2Fpgsql-hackers%2F&m=all&wf=11
and got the following error:
DB err: could not conn
It looks like the problem has been introduced by recent changes to dump
more stuff as "constraints". pg_dump is careful to dump indexes before
constraints --- but the latter category now includes not only foreign
key constraints, but unique/primary constraints, and those will all end
up sorted by
Joe Conway <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> > So where are the new array functions and syntaces documented?
>
> Mainly here:
> http://developer.postgresql.org/docs/postgres/arrays.html
excellent. thank you.
> > Specifically I want to know how to replace my int_array_aggregate(i
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On 28 Aug 2003, Gregory Stark wrote:
>> It seems when you create a new table with the "references" syntax the
>> constraint is created with a dependency specifically on a "primary key"
>> constraint on the target table.
>>
>> However when you alter a tab
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote:
> Mendola Gaetano wrote:
>
> >Hi all,
> >is not usefull have a mailing list in where people can
> >partecipate in a sort of "code revision" about the
> >actual code ?
> >
> Do you mean "code review"?
Yep, I'm a drunk dyslectic :-)
Gaetano
---
Do you mean "code review"?
andrew
Mendola Gaetano wrote:
Hi all,
is not usefull have a mailing list in where people can
partecipate in a sort of "code revision" about the
actual code ?
---(end of broadcast)---
TIP 8: explain analyze is your f
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
a_output := a_output || '' if v_'' ||
referrer_keys.kind || '' like ''
|| referrer_keys.key_string || ''
then return '' || referrer_keys.referrer
Greg Stark wrote:
So where are the new array functions and syntaces documented?
Mainly here:
http://developer.postgresql.org/docs/postgres/sql-expressions.html#SQL-SYNTAX-ARRAY-CONSTRUCTORS
http://developer.postgresql.org/docs/postgres/arrays.html
http://developer.postgresql.org/docs/postgres/funct
Hi all,
is not usefull have a mailing list in where people can
partecipate in a sort of "code revision" about the
actual code ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Just a follow up,
is it better to give a patch for this kind of stuff ?
Regards
Gaetano Mendola
""Mendola Gaetano"" <[EMAIL PROTECTED]> wrote:
> Hi all,
> I found this code on the file variables.c and
> in the function SetVariable I read:
>
> if (strcmp(current->name, name) == 0)
> {
>
I've traced through the failure reported here by Markus Kräutner:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg01132.php
What is happening is that as the UPDATE adds tuples (all with the same
hash key value) to the table, the hash bucket being filled eventually
requires more pages, and
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
Could s
Tom Lane writes:
> Beta2 is a done deal. When Bruce gets back from the seashore I expect
> he'll take a look at the issues you raised, but we're not holding off
> beta2 another week for that to happen.
Could someone tell the rest of the world ahead of time when release steps
are going to happen?
On Thu, 28 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > ... that would only help if the unique constraint were created before the
> > references constraint.
>
> But in any case, pg_dump ought to be careful to dump index creation
> commands before REFERENCES constraints
So where are the new array functions and syntaces documented?
Specifically I want to know how to replace my int_array_aggregate(int) and
int_array_enum(_int) calls. And how to replace my "arr *= n" calls too.
I think these are supposed be "ALL my_array" and "n = ANY myarray" or
something like t
My platforms are Unixware 713.
Am I right to be afraid that I have to pg_dump and reload?
Stiil it's amazind, 7.3 has been up for months and I discover the proclem
today...
Well, I don't reindex that often...
On Thu, 28 Aug 2003, Tom Lane wrote:
> Date: Thu, 28 Aug 2003 12:19:13 -0400
> From: Tom
David Schultz <[EMAIL PROTECTED]> writes:
> While looking into a block size mismatch problem between
> Postgresql and FreeBSD's FFS, I noticed that postgresql is making
> some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
> 0x4018, 0x8018, etc.
AFAICT the operative word there is "some" -
[EMAIL PROTECTED] writes:
> I've reinitdb (on 7.4b) with LANG=C and it worked.
> So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1 to
> recreate the db and it worked too...
That's weird. I don't understand why an initdb in the same locale would
make the problem go away.
> I
Stephan Szabo <[EMAIL PROTECTED]> writes:
> ... that would only help if the unique constraint were created before the
> references constraint.
But in any case, pg_dump ought to be careful to dump index creation
commands before REFERENCES constraints, I should think. If it isn't
doing that, there'
On 28 Aug 2003, Gregory Stark wrote:
> It seems when you create a new table with the "references" syntax the
> constraint is created with a dependency specifically on a "primary key"
> constraint on the target table.
>
> However when you alter a table to add a foreign key constraint the constraint
It seems when you create a new table with the "references" syntax the
constraint is created with a dependency specifically on a "primary key"
constraint on the target table.
However when you alter a table to add a foreign key constraint the constraint
is added with a dependency on any unique ind
Same issue - are there rpms anywhere for 7.3.4?
Thanks.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Sent: Wednesday, August 27, 2003 10:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] Org; [EMAIL PROTECTED]
Subject: Re: [GENERAL] before trigg
Jeroen Ruigrok/asmodai wrote:
Check constraints: "bugs_severity_cstr" ((bug_severity =
'blocker'::character varying) OR (bug_severity = 'critical'::character
varying) OR (bug_severity = 'major'::character varying))
If you have even more choices there (as Bugzilla does) you even get:
CONSTRAINT bu
Okay, so far,
I've reinitdb (on 7.4b) with LANG=C and it worked.
So I reinitDB with LANG=FR and used LANG=C to psql -f xxx.sql template1 to
recreate the db and it worked too...
I did'nt initdb between cvs changes, maybe that's why.
7.4b seems ok.
However, is there a way I can reindex on my 7.3.4
[EMAIL PROTECTED] writes:
> This is on unixware 7 (both 7.3.4 and 7.4b)
> I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
Okay. If you find it's still slow in C locale, the next thing to try
would be forcing use of our own qsort, as we already do for Solaris.
You'd need
While looking into a block size mismatch problem between
Postgresql and FreeBSD's FFS, I noticed that postgresql is making
some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
0x4018, 0x8018, etc. Most malloc(3) implementations round large
allocations up to a multiple of a large power of 2
[Please hold me on the to:/cc: list since I am not subscribed]
After talking this over with some of the great guys on IRC it was
suggested I ask here.
I am currently working on a document about how to convert from MySQL to
PostgreSQL (Sybase, Oracle, DB2, MS SQL Server are also going to be
done).
> > At the end of several bulk inserts the following statements get executed:
> >
> > begin
> > update pom_c2996785 set p3=3268837857008 where p3=34804837857008
> > update pom_c2996795 set p3=3268837857008 where p3=34804837857008
> > update pom_c2996804 set p3=3268837857008 where p3=34804837857008
Hi Tom,
This is on unixware 7 (both 7.3.4 and 7.4b)
I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
But I never had a problem before.
Waiting for a reply, I drop the table after copying it, and arranged sql
script to create the indexes BEFORE the COPY
The overall process
[EMAIL PROTECTED] writes:
> I've then pg_dump'ed the database and recreate an other both on 7.3.4 and
> 7.4b
> Both are still running after more than 30 minutes of CPU (100% cpu taken)
> creating the levt_lu_ligne_evt_key.
That's hard to believe. I get
regression=# SELECT levt_lu,count(*) from
Andreas Pflug <[EMAIL PROTECTED]> writes:
>> shouldn't it be datasize -= avail ?
>>
> AFAIR this is a really outdated K&R style of -= . Compilers *should*
> recognize this (and will throw an ambiguity error if there's no space
> after =- ), but it's better to use the 'newer' style.
Dave didn't
Dave Cramer <[EMAIL PROTECTED]> writes:
> This just doesn't look right.
Ugh, you're right.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Well, it get's worse, I think after bruce ran pgindent it was turned
into
datasize = -avail;
Dave
On Thu, 2003-08-28 at 08:19, Andreas Pflug wrote:
> Dave Cramer wrote:
>
> >This just doesn't look right.
> >
> >line 364
> >case COPY_NEW_FE:
> >
> > while (da
Markus =?iso-8859-15?q?Kr=E4utner?= <[EMAIL PROTECTED]> writes:
> I managed to construct a sample script which also fails in psql. It seems to
> be the hash index. If I leave out the "create index" line or use btree
> instead everything works fine.
> I will use btree now :)
Good idea ;-). I'll
Hi there,
new version of tsearch2 for 7.3.X is available for download from
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/.
Version for 7.4dev is available from CVS.
Changes:
* Change treating of stop words in boolean expression.
Earlier they were considered as always 'true', n
Hi every one,
I've tried to reindex one of my customer's table to gain some disk space.
I had to stop after 90 m cpu...
I've then pg_dump'ed the database and recreate an other both on 7.3.4 and
7.4b
Both are still running after more than 30 minutes of CPU (100% cpu taken)
creating the levt_lu_l
Dave Cramer wrote:
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize > 0 && !fe_eof)
line 408 datasize =- avail;
shouldn't it be datasize -= avail ?
AFAIR this is a really outdated K&R style of -= . Comp
I take that last remark back - it is there whether or not
CONFIG_SECURITY is defined or not. The code is in 2 places - ugh.
andrew
Andrew Dunstan wrote:
Yes, in 2.6, which is not yet released. Even after it is released I
expect it to take some time to bed down and make its way into vendor
rel
On Thursday 28 August 2003 17:11, Andrew Dunstan wrote:
> Yes, in 2.6, which is not yet released. Even after it is released I
> expect it to take some time to bed down and make its way into vendor
> releases, if the history of 2.4 is anything to go by.
Better late than never. I sincerely hope that
Yes, in 2.6, which is not yet released. Even after it is released I
expect it to take some time to bed down and make its way into vendor
releases, if the history of 2.4 is anything to go by.
Incidentally, it looks to me like it is only in 2.6 if your kernel is
built with CONFIG_SECURITY, which
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'
Hi all,
Following is from Documentation/vm/overcommit-accounting
-
2 - (NEW) strict overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize > 0 && !fe_eof)
line 408datasize =- avail;
shouldn't it be datasize -= avail ?
Dave
--
Dave Cramer <[EMAIL
On Wed, 27 Aug 2003, Bruno Wolff III wrote:
> Implicit froms aren't depreciated yet.
It would be really nice, to my mind, if they were killed stone dead.
I've been bitten several times by having an implicit FROM added to a
query that destroyed it.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81
On Tue, Aug 26, 2003 at 08:04:13PM -0400, Christopher Browne wrote:
>
> Interesting/positive news on this front; the XA specification
> documents are now all available in PDF form "freely", from the Open
> Group, where they used to be fairly pricey.
A step in the right direction, but AFAIC it's
On Wed, 27 Aug 2003, Kevin Brown wrote:
> There are some cases where it's extremely useful for PostgreSQL to
> accept dates of any format it knows about (ambiguities should be
> resolved either by looking at the current DateStyle or, failing that, by
> applying the recognition in a well-defined or
Larry Rosenman <[EMAIL PROTECTED]> writes:
> My UnixWare Thread.c patch/fix has been IGNORED.
> I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another
--On Wednesday, August 27, 2003 00:21:23 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
My UnixWare Thread.c patch/fix has been
[EMAIL PROTECTED] (Grant Succeeded) writes:
> The best for me by far, is to get the OS to *not* cache stuff. As
> long as the database uses the information it inherently has available,
> it can make far more effective use of the same amount of memory the OS
> would have used to cache the whole fil
Markus =?iso-8859-15?q?Kr=E4utner?= <[EMAIL PROTECTED]> writes:
> At the end of several bulk inserts the following statements get executed:
> begin
> update pom_c2996785 set p3=3268837857008 where p3=34804837857008
> update pom_c2996795 set p3=3268837857008 where p3=34804837857008
> update pom_c29
[EMAIL PROTECTED] (Tom Lane) wrote in message news:<[EMAIL PROTECTED]>...
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > better. AFAICS Vivek's problem is that it is hard enough to hold a
> > good part of the working set in the cache, and still his disks are
> > saturated. Now a VACUUM not only
On Wed, Aug 27, 2003 at 09:17:28PM +0200, Markus Kr?utner wrote:
> At the end of several bulk inserts the following statements get executed:
>
> begin
> update pom_c2996785 set p3=3268837857008 where p3=34804837857008
> update pom_c2996795 set p3=3268837857008 where p3=34804837857008
> update pom_
Hi,
can anyone give me some information about new approaches to integrate
tertiary memory devices into Postgres? Are there any news since the publication of
Olsen in 1992 ("Extending the Postgres Database System to manage tertiary
storage")?
Thanks!
Regards,
Thomas
--
COMPUTERBILD 15/03: Premi
Hi,
My name is Markus Kräutner, I am using PostgreSQL to build a distributed
biological database as part of my diploma thesis.
I hope this is the right forum for my question.
At the end of several bulk inserts the following statements get executed:
begin
update pom_c2996785 set p3=326883785700
You can always just go 'set datestyle...' before doing your insert I guess.
Chris
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Kevin Brown" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 28, 2003 11:36 AM
Subject: Re: [HACKERS] Date input changed in
"Marie G. Tuite" <[EMAIL PROTECTED]> writes:
> I have a problem with a before trigger raising a heap_mark4update error. It
> happens when there are many updates on the same key. OIDs are off
> presumably? Am running 7.3.2 on RH 7.3. Have looked around the archives
> and found nothing useful - a
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If it does not match your DateStyle setting, then yes.
> Umm...I hope this is controllable with a GUC variable then.
I was against that change myself, but I lost the argument.
regards, tom lane
Rod Taylor <[EMAIL PROTECTED]> writes:
> I would think that a simple optimization would be to push off evaluation
> of a subplan whenever possible by re-arranging AND statements.
Thought we did that already ... [ checks code ] ... hmph, it looks like
this is done correctly for quals attached to a
I have a problem with a before trigger raising a heap_mark4update error. It
happens when there are many updates on the same key. OIDs are off
presumably? Am running 7.3.2 on RH 7.3. Have looked around the archives
and found nothing useful - a mention of a known issue and a potential patch?
Or s
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Andrew
Sullivan) transmitted:
> As the 7.4 beta rolls on, I thought now would be a good time to start
> talking about the future.
>
> I have a potential need in the future for distributed transactions
> (XA). To get that f
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
Tom Lane wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > I noticed that some date are not anymore accepted:
> > test=# select '18/03/71'::date;
> > ERROR: invalid input syntax for date: "18/03/71"
> > is this the indendeed behaviour ?
>
> If it does not match your DateStyle setting, th
On Wed, Aug 27, 2003 at 12:21:25 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> I think that WARNING should be used for ALL things that have been
> deprecated. eg. implicit FROM, the opaque business, and definitely
> unsupported and ignored synacies.
Implicit froms aren't deprec
On Wed, 2003-08-27 at 00:07, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Christopher Kings-Lynne writes:
> >
> > > Surely a WARNING is a problem that you should probably fix?
> >
> > How are "should" and "probably" defined?
> >
> > > Or at least pay attention to.
> >
> > If it were in fa
Hi all,
I found this code on the file variables.c and
in the function SetVariable I read:
if (strcmp(current->name, name) == 0)
{
free(current->value);
current->value = strdup(value);
return current->value ? true : false;
}
this mean that if there is no me
100 matches
Mail list logo
