Hi,
A similar topic has been discussed before on pgsql-sql mailing list:
Subject: SELECT very slow Thomas Kellerer
URL: http://archives.postgresql.org/pgsql-sql/2005-06/msg00118.php
Regards.
On 7/6/05, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> Bug reference: 1756
> Logged by: Den
"Bennett, Steve" <[EMAIL PROTECTED]> writes:
>>> It appears that the timestamp 'epoch' is being interpreted as
>>> relative to the local timezone, rather than being an absolute time.
>>
>> This is correct for timestamp ... you want timestamp with time zone.
> Sorry, but that's dumb (IMHO). The un
It looks like bug 1473
(http://archives.postgresql.org/pgsql-bugs/2005-02/msg00143.php) is
causing octopus to fail
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&dt=2005-07-07%2018:05:02).
I suspect I can change config options or what-not to make the build
work, but I'm not sure if that wou
Hi,
I've been using pg_autovacuum for a while, and for the most part it's
been great. There's one case in my system where it won't run on a
particular type of table, even though the table apparently needs it.
I have a table called "properties" that has key->value pairs. Usually
there are o
On Thu, Jul 07, 2005 at 08:17:23AM -0700, John R Pierce wrote:
> Neil Conway wrote:
> >Denis Vlasenko wrote:
> >
> >>The same php script but done against Oracle does not have this
> >>behaviour.
> >
> >
> >Perhaps; presumably Oracle is essentially creating a cursor for you
> >behind the scenes. li
Tom Lane wrote:
Here's what I see in REL8_0_STABLE
and in HEAD (s_lock.c 1.35):
244 #ifdef SUNOS4_CC
245 asm(".seg \"data\"");
246 asm(".seg \"text\"");
247 #else
248 asm(".section \"data\"");
249 asm(".section \"text\"");
250 #endif
I see that template/sunos4 adds -DSUNOS4_CC
>> Here's what I see in REL8_0_STABLE
>> and in HEAD (s_lock.c 1.35):
>>
>> 244 #ifdef SUNOS4_CC
>> 245 asm(".seg \"data\"");
>> 246 asm(".seg \"text\"");
>> 247 #else
>> 248 asm(".section \"data\"");
>> 249 asm(".section \"text\"");
>> 250 #endif
I see that template/sunos4 adds -
I have seen that.
The question is: Gcc seems to get it right ;).
In my little world two compiler should handle this the same but I have
learned that Sun is in many cases different world ...
1+1 is always 2 - on Sun it could also be 3 ;).
hans
Michael Fuhr wrote:
On Thu, Jul 07, 2005
On Thu, Jul 07, 2005 at 09:51:54AM +0300, Denis Vlasenko wrote:
> I wanted to show colleagues which are Oracle admins that peak
> data fetch rate of PostgreSQL is way better than Oracle one.
>
> While it turned out to be true (Oracle+WinNT = 2kb TCP output buffer,
> ~1Mb/s over 100Mbit; PostgreSQ
Neil Conway wrote:
Denis Vlasenko wrote:
The same php script but done against Oracle does not have this
behaviour.
Perhaps; presumably Oracle is essentially creating a cursor for you
behind the scenes. libpq does not attempt to do this automatically; if
you need a cursor, you can create on
"Boris Sukholitko" <[EMAIL PROTECTED]> writes:
> It seems that the domain check constraint does not trigger
> an error when using prepared statement in perl's DBD::Pg 1.42.
I think this is the same issue discussed in this thread:
http://archives.postgresql.org/pgsql-interfaces/2005-07/msg6.ph
On Thursday 07 July 2005 08:54, Neil Conway wrote:
> Denis Vlasenko wrote:
> > Symptom: even the simplest query
> > $result = pg_query($db, "SELECT * FROM big_table");
> > eats enormous amounts of memory on server
> > (proportional to table size).
>
> Right, which is exactly what you would expect.
The following bug has been logged online:
Bug reference: 1759
Logged by: Boris Sukholitko
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.8
Operating system: Linux
Description:domain check constraint ignored in prepared statement
Details:
Hi,
It seems that
"Steve Bennett" <[EMAIL PROTECTED]> writes:
> It appears that the timestamp 'epoch' is being interpreted as
> relative to the local timezone, rather than being an absolute time.
This is correct for timestamp ... you want timestamp with time zone.
regards, tom lane
---
On Thu, Jul 07, 2005 at 04:53:16PM +0200, Hans-Jürgen Schönig wrote:
> I have some minor troubles when using the Sun Compiler 9 on Solaris 9.
> The spinlock assembler code is somehow broken for Solaris 9 and Solaris
> 10 (it works for Sun CC 8).
>
> The following patch fixes this:
>
> [EMAIL PRO
The following bug has been logged online:
Bug reference: 1757
Logged by: Steve Bennett
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux
Description:timestamp 'epoch' is not absolute
Details:
I'm seeing a rather annoying problem conv
On Wednesday 06 July 2005 16:52, Harald Armin Massa wrote:
> Denis,
>
> $result = pg_query($db, "SELECT * FROM big_table");
>
> you are reading a big result (as I suspect from big_table) into memory. It
> is perfectly normal that this uses large amounts of memory.
No, I am not reading it into m
I have some minor troubles when using the Sun Compiler 9 on Solaris 9.
The spinlock assembler code is somehow broken for Solaris 9 and Solaris
10 (it works for Sun CC 8).
The following patch fixes this:
[EMAIL PROTECTED] postgresql-8.0.1]$ cd src/backend/storage/lmgr/
[EMAIL PROTECTED] lmgr]$
Denis Vlasenko wrote:
The same php script but done against Oracle does not have this
behaviour.
Perhaps; presumably Oracle is essentially creating a cursor for you
behind the scenes. libpq does not attempt to do this automatically; if
you need a cursor, you can create one by hand.
-Neil
--
19 matches
Mail list logo
