Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Suppose that you run a checkpoint every 5 minutes, and with the knob
> > you slow down the checkpoint to extend over say 3 minutes on average,
> > rather than the normal blast-it-out-as-fast-as-possible. Then you'll
> > be keeping
> I ran some tests last week and can report results similar on Tom's test:
>
> pgbench -i -s 10 bench
> pgbench -c 10 -t 1 bench
>
> The tests were on a machine with a single SCSI drive that doesn't lie
> about fsync. I found 7.4.X got around 75tps while 8.0 got 100tps, very
> si
What are the open issues before we can release an RC3? I don't know of
any except the btree problem OSDL found. Is that fixed? Are their
others?
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a
Simon Riggs wrote:
> On Wed, 2004-12-22 at 04:43, Tom Lane wrote:
> > Bruce Momjian writes:
> > > So what are we doing for 8.0?
> >
> > Well, it looks like RC2 has already crashed and burned --- I can't
> > imagine that Marc will let us release without an RC3 given what was
> > committed today, n
--- Tom Lane <[EMAIL PROTECTED]> escribió:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > there is way to display all the values (fields) in
> a
> > tree node like this? for debug purpouses.
>
> > Query *query;
>
> Look at elog_node_display().
>
> regards, to
Where can I obtain a spec for postgresql, so I can start looking at the
code?
Benjamin
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
Jaime Casanova <[EMAIL PROTECTED]> writes:
> there is way to display all the values (fields) in a
> tree node like this? for debug purpouses.
> Query*query;
Look at elog_node_display().
regards, tom lane
---(end of broadcast)
Hi,
there is way to display all the values (fields) in a
tree node like this? for debug purpouses.
Query *query;
regards,
Jaime Casanova
_
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos
Greg Stark <[EMAIL PROTECTED]> writes:
> I think you want to extend the SQL syntax to allow updating views, and
> implement plan nodes and executor functionality to handle them. So things
> like this works:
> UPDATE (SELECT id,val FROM t) SET val=0 where id < 100
> Then the rules you create on th
Greetings,
As was discussed on IRC a bit- In the TODO list already there's a
blip about adding support for group ownership. In addition to this I
think it'd be nice if you could create a schema (owned by a group) in
which any tables/etc created were also owned by a group automatically.
The async interface is nice, but not really useful to me as it
requires
polling, instead of unblocking when an event comes through, which
would
create a vastly more real time interface that should be easier on the
database.
BTW, this is nonsense; the backend sends a message exactly when the
NOTIF
NOTIFY 'relname' a_expr;
This would be great to have...at least I think this is what you are
driving at: (adding a noiseword for readability)
LISTEN system_messages;
NOTIFY system_messages MESSAGE logoff;
NOTIFY request_unlock MESSAGE 12345; <-- for use with user locks!
Hrm... the userlock module
Sean Chittenden wrote:
> Option 1) Use sleep(3) for the given timeout and wake up on some
> interruptible a signal (USR2?). This is the simplest solution, but
> likely the least portable to win32. Given the new world order of 8.0
> and it's portability headaches, it's something I'm aware of.
>
>
Tom Lane wrote:
Are you using one of the scripts that
does an auto initdb if it doesn't see a valid PGDATA? 11 seconds might
be about right for that.
One problem with this theory is how come you didn't get screwed during
*that* boot cycle. It seems to require assuming that the NFS mount came
onli
Sean Chittenden <[EMAIL PROTECTED]> writes:
> The async interface is nice, but not really useful to me as it requires
> polling, instead of unblocking when an event comes through, which would
> create a vastly more real time interface that should be easier on the
> database.
BTW, this is nonsen
Sean Chittenden <[EMAIL PROTECTED]> writes:
> * Allow LISTEN to block until a value changes. LISTEN [BLOCK|WAIT]
> 'relname'
> * Allow LISTEN to have a timeout
>LISTEN name [BLOCK] [WITH] [TIMEOUT [=] ''::INTERVAL];
> * Allow blocking LISTEN queries to update the status of the proc title
>
On Mon, 27 Dec 2004 07:55:27 +0530 (IST), Ameya S. Sakhalkar
<[EMAIL PROTECTED]> wrote:
>
> For my project (main memory DBMS), I have written a main memory filesystem.
> Idea is, the primary copy of data will reside in main memory. (Workable
> only for small size data, at most 2GB).
>
> Now, I wa
> Basically I want to introduce formal support for turning
> PostgreSQL into a message bus. To start with, it won't be a
> scalable message bus that can scale to thousands of
> concurrent connections (that's something I'd like to do long
> term(tm), but I digress). The problem is with the BL
Howdy. I'm starting some work on our favorite LISTEN/NOTIFY subsystem
in the hopes of more advanced functionality. Right now I'm using a
bastardized (RAISE NOTICE + tailing error logs) + NOTIFY to get what
should just be built in to the LISTEN/NOTIFY interface. Here's the
syntax for the prop
19 matches
Mail list logo
