Like the article says, I wonder if these is any synergy between the
products. ie. Can we grab features from their codebase?
Wouldn't there be a license problem ?
Yes, Ingres may be able to pull features from PostgreSQL, but maybe it doesn't
work the other way.
--
Kaare Rasmussen
LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12
For comparison, 7.4.1 on the same system says:
LOG: database system was shut down at 2004-05-25 16:03:43 NZST
Can we keep the zic database convention unchanged but change the display
format in the logs to be
Zeugswetter Andreas SB SD wrote:
LOG: database system was shut down at 2004-05-25 15:15:44 GMT-12
For comparison, 7.4.1 on the same system says:
LOG: database system was shut down at 2004-05-25 16:03:43 NZST
Can we keep the zic database convention unchanged but change the display
format in
Hi All,
EXPLAIN ANALYZE
SELECT COUNT(*) AS c FROM articletbl WHERE (tarih BETWEEN '2004-04-24' AND
'2004-05-24')
result is :
QUERY PLAN
Aggregate (cost=40987.02..40987.02 rows=1 width=0) (actual
time=39209.476..39209.478 rows=1 loops=1)
- Seq Scan on articletbl (cost=0.00..40947.39
Gaetano,
I've changed my settings as :
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
#effective_cache_size = 1000# typically 8KB each
random_page_cost = 2# units are one sequential
Bruce Momjian wrote:
I am almost finished Andrew's version of pg_ctl.c. Here is the current
version I am using.
Sorry, I should have sent this to patches instead.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If
Oliver Jowett wrote:
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Also, unless I'm missing something, shouldn't Chile (Alvaro's timezone?)
be behind GMT (GMT-something) not ahead of it (GMT+something)?
Part of the confusion here is that the zone names in the zic
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
It is common practice that + is East and - is West, no ?
The SQL standard says that. The POSIX standard says the opposite.
Most of the Unixen I'm familiar with follow POSIX when choosing time
zone names.
The zic database is in itself a de
Ismail Kizir wrote:
Gaetano,
I've changed my settings as :
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
#effective_cache_size = 1000# typically 8KB each
random_page_cost = 2# units
Gaetano,
Hackers, what about to decrease the default values for this
quantities ?
Oh, I don't think Ismail has a bug, I think he probably just needs to tune his
database.
Ismail, join the PGSQL-PERFORMANCE mailing list and discuss this over there.
-HACKERS is not the appropriate place for
Josh Berkus wrote:
Gaetano,
Hackers, what about to decrease the default values for this
quantities ?
Oh, I don't think Ismail has a bug, I think he probably just needs to tune his
database.
I just only suggesting to decrease that values that are oversized for a modern
hardware.
Regards
Gaetano
Thanks Josh,
I'll subscribe to that group.
Regards
Ismail Kizir
- Original Message -
From: Josh Berkus [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Ismail Kizir [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 8:34 PM
Subject: Re: [HACKERS] Optimizer bug??
Gaetano,
Hackers, what about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Berkus wrote:
| Gaetano,
|
|
|I just only suggesting to decrease that values that are oversized for a
|
| modern
|
|hardware.
|
|
| Hey, have you had success with those settings that you suggested? I've tried
| tinkering with the relative CPU
I wrote:
Also, it's worth pointing out here that falling back to Etc/GMT+/-n
is intended to be just that, a last-ditch fallback that won't be seen
in normal practice. We still need to do some more work on
identify_system_timezone() to make that happen outside North America,
but I would like
Gaetano Mendola [EMAIL PROTECTED] writes:
I just only suggesting to decrease that values that are oversized for
a modern hardware.
I've seen no evidence saying that random_page_cost needs to be decreased
for modern hardware. Disk seek speed versus bandwidth hasn't changed
that much.
People
Tom,
You say that default values for optimizer are
efficient.
But this is evident that it doesn'tfunction
as expectedin my case.
I have a database of 20 tables, ~1gb total size. My
biggest table contains ~270,000 newspaper article from Turkish journals. I am
actually working on "fulltext
Oliver Jowett [EMAIL PROTECTED] writes:
Yes, exactly. Regardless of how the timezone is handled internally, showing
12-hours-east as GMT-12 in logs is horribly confusing.
Well, uh, you could always just pretend it was really 12-hours-west...
That doesn't help people in other time zones though
On Tue, May 25, 2004 at 03:01:24PM -0400, Tom Lane wrote:
I wrote:
Also, it's worth pointing out here that falling back to Etc/GMT+/-n
is intended to be just that, a last-ditch fallback that won't be seen
in normal practice. We still need to do some more work on
Ismail Kizir [EMAIL PROTECTED] writes:
I have a database of 20 tables, ~1gb total size. My biggest table contains
~270,000 newspaper article from Turkish journals. I am actually working on
fulltext search program of my own.
How much RAM does the machine have? Have you already executed the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, in the case you have an install prefix of /usr, we wouldn't want
relative installs because you would have /usr/bin and
/usr/lib/postgresql and that wouldn't be relocatable.
Why not?
ISTM that the algorithm should go
Following example is with latest anonymous cvs of 7.5.
I can't get LIKE to use an index even with seq_scan = off. I'm using
the default locale and hchassis.vin_no is defined as char(17). The
hchassis table has about 250k rows in it. The non aggregate versions of
the selects have the same
I've spoken to Merlin off-list and confirmed this issue will be fixed in
the locale fix I'll post shortly. The reason being that the backend
thought it was in a non-C locale (the window system default locale which
is specifically *not* C), and in non-C locale LIKE is not indexable.
//Magnus
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I just only suggesting to decrease that values that are oversized for
a modern hardware.
I've seen no evidence saying that random_page_cost needs to be decreased
for modern hardware. Disk seek speed versus bandwidth hasn't changed
that
On Fri, Apr 23, 2004 at 05:10:34PM -0400, Alvaro Herrera wrote:
In current (as of a couple hours ago) clean CVS tip sources, without any
of my local changes, I'm getting a postmaster segfault when trying to
connect to a non existant database.
Just to follow up, I no longer see this problem in
Ismail Kizir [EMAIL PROTECTED] writes:
I am sure default values are erronous.
Perhaps they are --- for your database, on your hardware. Or perhaps
the problem is somewhere else (we know that the costing of nestloop
indexscan joins needs work, for instance). But in any case there's
a reason why
Tom Lane wrote:
BTW, as of an hour or so ago, identify_system_timezone is a bit smarter
than before. Please try it and see if it gets it right on your machine.
Looks good:
LOG: database system was shut down at 2004-05-26 12:43:55 NZST
test=# select now();
now
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I notice that when using the extended query protocol, statement logging
appears to happen only when a Parse message is received. This is less
than ideal:
I agree, but I didn't have time at the end of the 7.4 development cycle
to work out
I am actually
working on fulltext search program of my own.
No need, use contrib/tsearch2
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Tue, May 25, 2004 at 03:08:59PM -0300, Tom Lane wrote:
Add code to identify_system_timezone() to try all zones in the zic
database, not just ones that we cons up POSIX names for. This looks
grim but it seems to take less than a second even on a relatively slow
machine, and since it only
Alvaro Herrera wrote:
On Tue, May 25, 2004 at 03:08:59PM -0300, Tom Lane wrote:
Add code to identify_system_timezone() to try all zones in the zic
database, not just ones that we cons up POSIX names for. This looks
grim but it seems to take less than a second even on a relatively slow
I've applied the list rewrite patch to CVS HEAD. I've also sent a
copy of the patch I applied to the -patches list.
Notes:
- the tree compiles without warnings and passes the regression
tests. I'm not aware of any bugs, regression failures, or compiler
warnings caused by the list rewrite patch
- anything else?
All compiles and passes regression tests on FreeBSD...
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message
32 matches
Mail list logo
