Am 22.11.2013 16:15, schrieb Tom Lane:
[ memo to self: never, ever accept another contrib module whose name
isn't a plain SQL identifier ]
Well, in that case and since this is a rarely used extension (I guess
so), maybe it would be the best to simply rename that extension to
uuidossp (or
Am 01.12.2010 15:37, schrieb Rob Wultsch:
For beginners, a useful startup option is --safe-updates (or
--i-am-a-dummy, which has the same effect). This option was introduced
in MySQL 3.23.11. It is helpful for cases when you might have issued a
DELETE FROM tbl_name statement but forgotten the
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
I found the discussion about log compressing here:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00502.php
But I cannot find the scripts (pg_compresslog/pg_decompresslog), how can I get
those? Will this work for 8.1 branch too? I want to use PITR, but archiving
over one days will
.
Best regards,
Mario Weilguni
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Marko Kreen schrieb:
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote:
Could someone using the pgcrypto extension please verify this?
SELECT encode(digest(null, 'md5'::text), 'hex');
or
SELECT digest(null, 'md5');
Takes a few seconds, and then crashes the server with a Signal 11. My
Marko Kreen schrieb:
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote:
Marko Kreen schrieb:
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote:
Could someone using the pgcrypto extension please verify this?
SELECT encode(digest(null, 'md5'::text), 'hex');
or
SELECT digest
updates.
Best regards,
Mario Weilguni
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
But in PLPGSQL, we can only open a cursor this way:
open cursorSrc for select * from testtable;
We cannot substitude select * from testtable with a variable.
Is there another way to handle it?
Thank you for your help. :-)
open cursorSrc for execute queryStr; should work fine
Regards
Mario
Mike schrieb:
Hello,
I’m new to the core PostgreSQL code, so pardon the question if the
answer is really obvious, and I’m just missing it, but I’ve got a
relatively large web application that uses PostgreSQL as a back-end
database, and we’re heavily using memcached to cache frequently
Tom Lane schrieb:
Jonah H. Harris [EMAIL PROTECTED] writes:
I've run into a couple cases now where it would be helpful to easily
assign an already-existing unique index as a primary key.
You need to present a more convincing use-case than this unsupported
assertion. There's hardly
There's a IMO a problem with pg_restore, it should be easy to fix (I
hope - and I could try to fix it and send a patch).
* I've a dump taken from a 8.1 database
* I'm using gist and ltree
* I'm restoring to a 8.2 database
Problem:
I cannot use -1 for performance, because some gist stuff has
Heikki Linnakangas schrieb:
Mario Weilguni wrote:
I cannot use -1 for performance, because some gist stuff has changed
and the restore fails. But there seems to be no option for pg_restore to
use transactions for data restore, so it's very very slow (one million
records, each obviously
,
and reject them in the validation stage?
Regards
Mario Weilguni
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
until they are presented
with a failing restore.
Is there anything I can do to help with this problem? Maybe implementing a new
GUC variable that turns off accepting wrong encoded sequences (so DBAs still
can turn it on if they really depend on it)?
For me,
Best regards,
Mario Weilguni
this is an
error, making restoration very complicated in such cases...
Or am I doing something completly wrong here?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index
Am Dienstag, 13. März 2007 14:46 schrieb Albe Laurenz:
Mario Weilguni wrote:
Steps to reproduce:
create database testdb with encoding='UTF8';
\c testdb
create table test(x text);
insert into test values ('\244'); == Is akzepted, even if not UTF8.
This is working as expected, see
with pg_restore.
A dangerous feature IMO, and will make a lot of DB admins very unhappy if they
have to validate every day if the precious database dumps can be restored in
case of an error.
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP
to use
iconv. Did I miss something?
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
difficult to find a self contained patch, but if
necessary I'll give it a try.
I could give 8.2.3 a try, but I doubt this will help.
Any ideas?
Regards
Mario Weilguni
---(end of broadcast)---
TIP 4: Have you searched our list archives
Thanks for the info. Is there a fix for 8.1 branch, the production system is
still 8.1.
Regards
Mario Weilguni
Am Donnerstag, 15. Februar 2007 16:25 schrieb Alvaro Herrera:
Mario Weilguni wrote:
Interesting: remove any of the above where conditions solves the problem
go away, e.g
') should be constant and marked immutable, or am I
wrong here? Or is it not marked immutable because of possible changes on
date_format?
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ
Am Freitag, 12. Januar 2007 14:48 schrieb Martijn van Oosterhout:
On Fri, Jan 12, 2007 at 11:55:07AM +0100, Mario Weilguni wrote:
to_char(timestamp, '') should be constant and marked immutable,
or am I wrong here? Or is it not marked immutable because of possible
changes on date_format
with -c last
month, when I noticed that this will not work:
psql -c set client_encoding=iso-8859-1; select name from customer (UTF8
database, output is hmmm... broken german umlauts).
Best regards
Mario Weilguni
---(end of broadcast)---
TIP 1
Uh, we did that years ago.
Really?
+ o Add ALTER TABLE RENAME COLUMN (should rename appropriate sequences and
constraints)
Sounds like this is not done, at least not renaming sequencens and constraints,
or am I wrong here?
Regard
Mario Weilguni
-Ursprüngliche Nachricht
do:
Alter sequence foo_bar_seq rename to foo_baf_seq;
Alter table foo alter baf set default nextval('foo_baf_seq')
-Ursprüngliche Nachricht-
Von: Jonah H. Harris [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 17. November 2006 16:27
An: Mario Weilguni
Cc: Tom Lane; Jim Nasby; PostgreSQL
Am Mittwoch, 18. Oktober 2006 13:52 schrieb Andreas Joseph Krogh:
This has been been discussed before, but Oracle behaves differently, and
IMHO in a more correct way.
The following query returns NULL in PG:
SELECT NULL || 'fisk';
But in Oracle, it returns 'fisk':
SELECT NULL || 'fisk' FROM
If you want this behaviour you will have to explicitly handle it with
COALESCE().
regards,
Lukas
True. But there's a point where oracle is really better here, they named
coalesce nvl = a lot easier to type ;-)
---(end of broadcast)---
TIP 3: Have
Nice, but I still prefer nvl. Coalesce is hard to pronounce, and even harder to
type.
-Ursprüngliche Nachricht-
Von: Andreas Joseph Krogh [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 18. Oktober 2006 15:48
An: pgsql-hackers@postgresql.org
Cc: Mario Weilguni
Betreff: Re: [HACKERS] bug
Yes it's hard for me, maybe because I am no native english speaker.
-Ursprüngliche Nachricht-
Von: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 18. Oktober 2006 16:11
An: Lukas Kahwe Smith
Cc: Mario Weilguni; pgsql-hackers@postgresql.org
Betreff: Re: [HACKERS] bug
This works as intended. Try this:
select coalesce(lower(firstname), '') || ' ' || coalesce(lower(lastname), '')
from person
Concating something unknown (=NULL) and a string = unknown (=NULL)
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
What about the char type? Isn't it designed for that? Or will this type
disappear in future releases?
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Heikki
Linnakangas
Gesendet: Freitag, 15. September 2006 13:35
An: Martijn van Oosterhout
Cc:
, the other one
the webserver.
Any ideas?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Will this patch make it into 8.2?
http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
It's a really nice feature, would be extremly useful with tools like pgpool.
Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian:
There are roughly three weeks left until the feature freeze on
Am Donnerstag, 22. Juni 2006 16:09 schrieb Csaba Nagy:
[...]
There has to be a more linear way of handling this scenario.
So vacuum the table often.
Good advice, except if the table is huge :-)
Here we have for example some tables which are frequently updated but
contain 100 million
-limited )
backward compatible option.
regards
mario weilguni
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Yesterday I helped a guy on irc with a locking problem, he thought
that locking in postgresql was broken. It turned out that he had a PHP
function that he called inside his transaction and the
Am Mittwoch, 10. Mai 2006 09:41 schrieb Mario Weilguni:
Am Mittwoch, 10. Mai 2006 08:19 schrieb Tom Lane:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Yesterday I helped a guy on irc with a locking problem, he thought
that locking in postgresql was broken. It turned out that he had a PHP
Am Mittwoch, 10. Mai 2006 10:59 schrieb Peter Eisentraut:
Am Mittwoch, 10. Mai 2006 10:10 schrieb Martijn van Oosterhout:
You want to make a GUC that makes:
BEGIN;
BEGIN;
Leave you with an aborted transaction? That seems like a singularly
useless feature...
If a command doesn't do
Am Mittwoch, 10. Mai 2006 11:44 schrieb Bernd Helmle:
--On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
[EMAIL PROTECTED] wrote:
No, I want that there is a setting or GUC that controls whether an error
or a warning is raised when begin is executed within a transaction. I
know
to_timestamp is only for Oracle compatibility? I always thought it's some sort
of sql standard. What's the sql compliant way to do this?
Regards,
mario weilguni
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tom Lane
Gesendet: Freitag
','mmdd hh24mi');
to_timestamp
0509-10-10 04:00:00+01
I think all except the first one should raise a warning, isn't it? Where can I
find the source code of this function?
Best regards,
Mario Weilguni
---(end of broadcast
Am Donnerstag, 6. April 2006 14:57 schrieb Mario Weilguni:
mydb=# select to_timestamp(' 0300','mmdd hh24mi');
to_timestamp
---
0001-01-01 03:00:00+01 BC
(1 row)
Questionable, but probably valid.
mydb=# select to_timestamp(' 0300
the statements of both
backends (if available). Would make detecting such errors quite easier.
Best Regards,
Mario Weilguni
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
Am Dienstag, 13. Dezember 2005 16:35 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
Version: 8.1
Query: update last_modified set dataend=now() where type='list'
DB-Error : ERROR: deadlock detected
DETAIL: Process 10454 waits for ShareLock on transaction
Am Dienstag, 13. Dezember 2005 16:52 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
Since the type field is PK, there cannot be 2 rows with type='list', I
guess the deadlock must have some different explanation.
Then the deadlock must involve rows in two different tables. What
) applications. We using
linux bonding interface with 2 gbit NICs, and 200 MBytes/sec throughput is
something you need to have a quite some harddisks to reach that. Latency is not
bad too.
Regards,
Mario weilguni
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Title: AW: [HACKERS] Strange left join problems in 8.1
I've tried this with cvs , -r REL8_1_STABLE (hope this was the right one), and works flawless now.
Thanks a lot!
Best regards
Mario Weilguni
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]]
Gesendet: Sa
k_protokoll blp (cost=0.00..68.16 rows=9
width=8) (actual time=0.115..1.189 rows=3
loops=1)
Filter: (grund =
''notify_verschickt_frei'::text)
- Sort (cost=21.37..21.52 rows=60 width=17) (actual
time=0.230..0.266 rows=60
loops=1)
Sort Key:
mq.id
- Seq Scan on abw_mailqueue mq (cost=0.00..19.60 rows=60
width=17) (actual time=0.006..0.166 rows=60 loops=1)Total runtime:
1.702 ms(15 rows)
It seems like the
planner is pulling the last where condition into the second left join,
evaluating it in wrong order.
Any idea what's
going wrong here?
Best
regards,
Mario Weilguni
can give it a try, do I need to re-initdb when I use cvs to
checkout 8.1 tip? I don't think so, isn't it?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org
,
Mario Weilguni
icomedias - Digitale Kommunikation
Mario Weilguni, Forschung und Entwicklung
[EMAIL PROTECTED], http://www.icomedias.com/
icomedias Österreich Systemhaus GmbH:
8020 Graz, Entenplatz 1
Tel: +43
Am Dienstag, 29. November 2005 10:05 schrieb Mario Weilguni:
Hello Tom,
I tried both patches on a different machine (but had to take the patches
from cvs diff, cut'n paste from the mail-program did not work). Up until
now, they work like a charm, correct results and fast. I will try
is an ltree column, with an GIST index on it.
Any ideas what I could try to track this down?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Am Montag, 28. November 2005 14:12 schrieb Christopher Kings-Lynne:
The path field is an ltree column, with an GIST index on it.
Something to do with bitmap indexscans on lossy indexes?
Chris
I doubt that, set enable_bitmapscan to off produces the wrong result as
well.
Best regards
Mario
,
Mario Weilguni
icomedias - Digitale Kommunikation
Mario Weilguni, Forschung und Entwicklung
[EMAIL PROTECTED], http://www.icomedias.com/
icomedias Österreich Systemhaus GmbH:
8020 Graz, Entenplatz 1
Tel: +43 (316
would take ~100-500 milliseconds).
I will check the patch on a different machine again and inform you of
the results.
Best regards,
Mario Weilguni
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 6:09 PM
To: Mario Weilguni
Cc: pgsql
: (ben_id = $0)
Total runtime: 501.980 ms
Best regards
P.s. sorry for the stupid quoting, I've to use Outlook
Mario Weilguni [EMAIL PROTECTED] writes:
The failing case is:
...
SubPlan
- Hash Join (cost=8.47..19.46 rows=1 width=0) (actual
time=0.004..0.004 rows=0 loops=21619
the query to use IN instead of exists.
I'll compile again and try it again.
Thanks alot!
Best regards,
Mario Weilguni
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]]
Gesendet: Mo 28.11.2005 19:39
An: Mario Weilguni
Cc: pgsql-hackers@postgresql.org
Betreff: Hashjoin
9223372036854775807
START 0
CACHE 1;
GRANT ALL ON TABLE sqlserver.uniqueidentifier1 TO public;
Why do you use GRANT ALL and not GRANT SELECT, UPDATE? All means everybody
can do bad things with those sequences.
Regards,
Mario Weilguni
---(end of broadcast
-defined order, maybe ordered by the oid of the
pgclass entry.
In my case, it always happens on INSERT activity (no updates on those tables,
just inserts), but I hope the above problem might be the solution for the
insert deadylock too.
Does this sound reasonable?
Regards,
Mario Weilguni
Alvaro Herrera:
Mario Weilguni wrote:
Hi,
T1: BEGIN;
T2: BEGIN;
-- these are the queries similar to those from the foreign key code
T1: SELECT 1 FROM ONLY lookup1 x WHERE id = 1 FOR UPDATE OF x;
T2: SELECT 1 FROM ONLY lookup2 x WHERE id = 3 FOR UPDATE OF x;
T1: SELECT 1 FROM ONLY lookup2
column for sorting.
Any ideas?
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 6: explain analyze is your friend
Since 7.4 we have troubles with ltree (seldom corruption of buffer cache, not
on-disk), might this bug be somehow related to the ltree problem?
7.2 was rock-stable with ltree.
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 9: In versions
mail, on-disk was broken too.)
Might this be somehow related to the intarray bugs?
Best regards,
Mario Weilguni
p.s.: I tried hard to create a self-contained test for tracking this down, but
failed.
---(end of broadcast)---
TIP 3: Have you checked
JFYI:
Allow indexes to be used for MIN/MAX (Tom)
In previous releases, the only way to use index for MIN/MAX was to
rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. This not
happens automatically.
I guess this should read This now happens automatically
Regards,
Mario
Am Freitag, 15. Juli 2005 14:19 schrieb Greg Sabino Mullane:
The use case is when you want to prepare a query, but only if it's not
already prepared on that connection.
This has been covered before, but to reiterate: why would you need this?
Any application worth its salt should be tracking
I've quite some trouble with the overlaps function:
SELECT overlaps('9.6.2005'::date, '9.6.2005'::date, '9.6.2005'::date,
'9.6.2005'::date);
returns true (these are german timestamps dd.mm.)
SELECT overlaps('8.6.2005'::date, '9.6.2005'::date, '9.6.2005'::date,
'9.6.2005'::date);
returns
Am Dienstag, 19. April 2005 09:18 schrieb Honza Pazdziora:
Hello,
the nls_string function that makes it possible to sort by arbitrary
locale has been updated to reflect the changes in error handling in
PostgreSQL 8.0, due to users using the nls_string sorting on 7.4 and
requesting it for 8.0
Because their SQL queries always seem to need a target object to select
from. i.e. SELECT NEXTVAL.foo isn't valid for Oracle 8/9.
It has been a long time since I've used Oracle, but shouldn't it be select
foo.nextval from dual?
Regards,
Mario Weilguni
such problems? Even a simple dump to
stdout would be helpful.
Thanks!
Regards,
Mario Weilguni
p.s. I've checked the hardware before going online with that database, RAM is
definitly ok, and the rest of the hardware should work fine as well.
The table was vacuumed full, but vacuum did not report
on the history page
http://www.drbd.org/releases.html
maybe it's not release status yet - thus no option for now.
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have mentioned
installed 7.5 on a development machine yesterday, changed to JFS
filesystem, and so
far the system feels more responsive, but I've yet to test it. 7.5 on my personal PC
performed very fine, especially
with some more problematic queries it produced better query plans.
Regards,
Mario Weilguni
that. XFS is no option since it does not
work with drbd,
but jfs seems to be quite good.
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Am Tuesday 06 January 2004 21:30 schrieb Jon Jensen:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something
% are often too much, in my case it's typically below 1%.
The statistic collector could even tell the optimizer if an index scan is the
way to go...
Would that work?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: you can get
?
That's the problem, for every performance test they choose ISAM tables, and
when transactions are mentioned it's said MySQL has transactions. But why
no benchmarks?
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 3: if posting/reading through
quotes? However, one
would expect the same output from both queries, either the error message, or
better the 0 rows result.
Regards
Mario Weilguni
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
I was playing with the Japanese win32 7.2.1 port and I noticed that select
0 / 0 caused the server to crash and restart. I understand that it is a
totally unsupported version, but it should be easy enough to check vs. the
current version. Note that select 0.0/0.0 worked fine!
Seems to work fine
applications, for
example I've a case with a table with 20 rows where 4 values (of type
text) are not null. The index size would be much smaller without all those
NULL values.
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 1: subscribe
You can try an index like:
create index str_idx_url on str(url) where url = '';
I think that should be identical. ('' is the smallest string, no ?)
Thanks alot, it works now. But I still think the NOT NULL case would be
useful.
Best regards,
Mario Weilguni
any more. Might this notice indicate a serious
problem?
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
scan is possible but not used:
EXPLAIN SELECT * FROM copy_of_forum_list_child WHERE f_id = 1 and
father_name = 'top';
Seq Scan on copy_of_forum_list_child (cost=0.00..2.44 rows=1width=100, costs using
index: 0.00...9.44 rows=... with=...)
Any comments?
Regards,
Mario Weilguni
a compatible (a page file with the same number of attributes) page file
is used. Especially master-detail tables would
profit from this, reducing the tuple overhead by another 9%.
Might this be possible?
Regards,
Mario Weilguni
---(end of broadcast
Am Freitag, 11. Oktober 2002 14:12 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
Is it possible to get rid of the t_natts fields in the tuple header?
Is this field only for alter table add/drop support?
Only? A lot of people consider that pretty important ...
With only I
);
dbms_output.put_line(s2);
end;
/
set serverout on
execute foobar;
Hope it helps.
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
systems.
http://hpc.uky.edu/cgi-bin/man.cgi?section=alltopic=fgetpos64
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL
from mytable where id::text=''
Regards,
Mario Weilguni
-- Weitergeleitete Nachricht --
Subject: [HACKERS] int type problem in 7.3
Date: Wed, 2 Oct 2002 08:31:45 +0200
From: Mario Weilguni [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
It seems queries like:
select ... from
.
No, oracle accepts this and works correctly with number() datatype.
However I did not know that in postgres '' was treated as '0'.
Regards,
Mario Weilguni
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
It's just a cosmetic change, fixes the help screen. Should be applied in
/contrib/vacuumlo
Regards,
Mario Weilguni
--- ../vacuumlo.c Thu Sep 5 23:19:13 2002
+++ vacuumlo.c Wed Oct 2 18:03:29 2002
@@ -383,7 +383,6 @@
fprintf(stdout, -U username\tUsername to connect
This small patch adds a Makefile for /contrib/reindexdb/ and renames the README to
README.reindexdb.
Regards,
Mario Weilguni
diff -Nur postgresql-7.3b2.orig/contrib/reindexdb/Makefile postgresql-7.3b2/contrib/reindexdb/Makefile
--- postgresql-7.3b2.orig/contrib/reindexdb/Makefile
,
Mario Weilguni
icomedias communication solutions/graz . berlin
---
icomedias ist Hersteller von icocms: Information-
und Content Management System für Inter- UND INTRAnet
---
Mario Weilguni
I noticed some other minor differences between 7.2 and 7.3:
* 7.2: select now() + '1 minute'::timespan = works
* 7.2: select now() + '1 minute'::reltime = works
* 7.3: select now() + '1 minute'::timespan = does not work (Type timespan does not
exist)
* 7.3 select now() + '1 minute'::reltime =
/link that directory
on a device that is on a separate SCSI channel is what I can think of as
last drop of performance out of it..
(snip)
I think a good approach would be the introduction of tablespaces like oracle has, and
assigning locations to that tablespace.
Best regards,
Mario
On 26 Sep 2002 at 14:05, Shridhar Daithankar wrote:
Some time back I posted a query to build a site with 150GB of database. In
last
couple of weeks, lots of things were tested at my place and there are some
results and again some concerns.
2) Creating index takes huge amount of time.
Well the test runs were for 10GB of data. Schema is attached. Read in fixed
fonts..Last nullable fields are dummies but may be used in fututre and
varchars
are not acceptable(Not my requirement). Tuple size is around 100 bytes..
The index creation query was
CREATE INDEX index1 ON tablename
be sufficient.
Best regards,
Mario Weilguni
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
OK, I have a better version at:
The script is now broken, I get:
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...
Running null loop timing test ...
random test: 14
sequential test: 16
null timing test: 14
random_page_cost
I'm stuck for strange reason!
This is my first attempt to use pg_lo concept in my apps:
...
Oid oid;
PGconn* dbcon = PQconnectdb(conninfo.c_str());
oid = lo_creat(dbcon, INV_WRITE | INV_READ);
int pgfd = lo_open(dbcon, oid, INV_WRITE | INV_READ);
...
lo_open ALWAYS returns -1
What do other people get for this value?
Keep in mind if we increase this value, we will get a more sequential
scans vs. index scans.
With the new script I get 0.929825 on 2 IBM DTLA 5400RPM (80GB) with a 3Ware
6400 Controller (RAID-1)
Best regards,
Mario Weilguni
--
Bruce
1 - 100 of 136 matches
Mail list logo
