On Thu, 3 Nov 2005, Tom Lane wrote:
>
> On Unix I get a dead flat line (within measurement noise), both local
> loopback and across my LAN.
>
> after 5 30.20 sec
> after 10 31.67 sec
> after 15 30.98 sec
> after 20 29.64 sec
> after 25 29.83 sec
>
Confirmed in Linux. And on
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ok, I generated a test case which was 250k inserts to simple two column
> table all in single transaction. Every 50k inserts, time is recorded
> via timeofday().
You mean something like the attached?
> Running from remote, Time progression is:
> F
> > Sorry, I don't follow you here - what do you mean to do? Remove the
> > event completely so we can't wait on it?
> >
>
> I'd like to use the win32 provided recv(), send() functions instead of
> redirect them to pgwin32_recv()/pgwin32_send(), just like libpq does.
If
> we do this, we will lose
On Thu, 3 Nov 2005, Magnus Hagander wrote:
> > Both win32 send/recv have pgwin32_poll_signals() in them.
> > This is glorified WaitForSingleObjectEx on global
> > pgwin32_signal_event. This is probably part of the problem.
> > Can we work some of the same magic you put into check
> > interrupts
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
> Not to 100%, so this means the server is always starving. It is waiting on
> something -- of couse not lock. That's why I think there is some problem
> on network communication. Another suspect will be the write - I knwo NTFS
> system will issue an
I recently upgraded my DB from 7.4.3 to 8.0.4 and I've noticed the following errors appearing in my serverlog:
2005-11-03 05:56:57 CST 127.0.0.1(38858) ERROR: Unicode characters greater than or equal to 0x1 are not supported
2005-11-03 06:04:09 CST 127.0.0.1(38954) ERROR: invalid byte s
""Merlin Moncure"" <[EMAIL PROTECTED]> wrote
>
> Running from remote, Time progression is:
> First 50k: 20 sec
> Second: 29 sec
> [...]
> final:: 66 sec
>
This may due to the maintainence cost of a big transaction, I am not sure
... Tom?
> so, clear upward progression of time/rec. Init
> > > I'd like to use the win32 provided recv(), send()
> functions instead
> > > of redirect them to pgwin32_recv()/pgwin32_send(), just
> like libpq
> > > does. If we do this, we will lose some functionalities,
> but I'd like
> > > to see the performance difference first. -- do you think
>
On Thu, 3 Nov 2005, Magnus Hagander wrote:
> > > Sorry, I don't follow you here - what do you mean to do? Remove the
> > > event completely so we can't wait on it?
> > >
> >
> > I'd like to use the win32 provided recv(), send() functions
> > instead of redirect them to pgwin32_recv()/pgwin32_sen
> > Sorry, I don't follow you here - what do you mean to do? Remove the
> > event completely so we can't wait on it?
> >
>
> I'd like to use the win32 provided recv(), send() functions
> instead of redirect them to pgwin32_recv()/pgwin32_send(),
> just like libpq does. If we do this, we will lo
> > > Both win32 send/recv have pgwin32_poll_signals() in them.
> > > This is glorified WaitForSingleObjectEx on global
> > > pgwin32_signal_event. This is probably part of the problem.
> > > Can we work some of the same magic you put into check interrupts
> > > macro?
> > >
> >
> > Uh, we alrea
On Thu, 3 Nov 2005, Magnus Hagander wrote:
>
> Sorry, I don't follow you here - what do you mean to do? Remove the
> event completely so we can't wait on it?
>
I'd like to use the win32 provided recv(), send() functions instead of
redirect them to pgwin32_recv()/pgwin32_send(), just like libpq
Just as an FYI, if you want to reassure yourself that the ORDER BY
is being applied as intended, you could do the following:
(
select 1 as hint, start_time as when [...]
union all
select 2 as hint, end_time as when [...]
) order by seq, when
This is ANSI/ISO standard, and works in PostgreSQL (
> Both win32 send/recv have pgwin32_poll_signals() in them.
> This is glorified WaitForSingleObjectEx on global
> pgwin32_signal_event. This is probably part of the problem.
> Can we work some of the same magic you put into check
> interrupts macro?
>
> ISTM everything also in win32 functio
On Nov 3, 2005, at 10:21 AM, Merlin Moncure wrote:
Reading the previous paragraphs I was just about to suggest this.
This
is a much more elegant method...you are reaping the benefits of having
normalized your working set. You were trying to denormalize it
back to
what you were used to. Ye
> Both win32 send/recv have pgwin32_poll_signals() in them. This is
> glorified WaitForSingleObjectEx on global pgwin32_signal_event. This
is
> probably part of the problem. Can we work some of the same magic you
put
> into check interrupts macro?
Whoop! following a cvs update I see this is alr
> The ANSI/ISO specs are not at all ambiguous on this. An
> ORDER BY is not allowed for the SELECT statements within
> a UNION. It must come at the end and applied to the resulting
> UNION.
Interesting :/
Merlin
---(end of broadcast)---
TIP 6: e
The ANSI/ISO specs are not at all ambiguous on this. An
ORDER BY is not allowed for the SELECT statements within
a UNION. It must come at the end and applied to the resulting
UNION.
Similarly, the column names in the result come from the first
query in the UNION. Column names in the query on th
> Wow. I hadn't known about generate_series, but there are a bunch of
> places I've needed it.
It's a wonder tool :).
> But I think there is something I can do: I can just do a query of the
> transaction table sorted by start time. My graph tool can keep a
Reading the previous paragraphs I was
> On Wed, 2 Nov 2005, Merlin Moncure wrote:
> If you put client/server on the same machine, then we don't know how
the
> CPU is splitted. Can you take a look at the approximate number by
> observing the task manager data while running?
ok, I generated a test case which was 250k inserts to simple t
On Nov 3, 2005, at 8:20 AM, Merlin Moncure wrote:
select t, (select count(*) from transaction where t between happened
and when_stopped) from
(
select ((generate_series(1,60) * scale)::text::interval) + '12:00
pm'::time as t
) q;
Wow. I hadn't known about generate_series, but there are a b
> Merlin Moncure wrote:
> > hmm, try pushing the union into a subquery...this is better style
> > because it's kind of ambiguous if the ordering will apply
before/after
> > the union.
>
> Seems to be a little slower. There's a new "subquery scan" step.
I figured. However it's more correct, I'm
Merlin Moncure wrote:
hmm, try pushing the union into a subquery...this is better style
because it's kind of ambiguous if the ordering will apply before/after
the union.
Seems to be a little slower. There's a new "subquery scan" step.
explain analyze
selectq.when_happened from (
> Postgresql 8.0.4 using plpgsql
>
> The basic function is set up as:
> CREATE FUNCTION add_data(t_row mytable) RETURNS VOID AS $func$
> DECLARE
> newtable text;
> thesql text;
> BEGIN
> INSERT INTO newtable thename from mytable where lookup.id =
> t_row.id;
> thesql := 'INSERT INT
Postgresql 8.0.4 using plpgsql
The basic function is set up as:
CREATE FUNCTION add_data(t_row mytable) RETURNS VOID AS $func$
DECLARE
newtable text;
thesql text;
BEGIN
INSERT INTO newtable thename from mytable where lookup.id =
t_row.id;
thesql := 'INSERT INTO ' || newtable || VAL
> selectwhen_stopped as when_happened,
>1 as order_hint
> from transaction t
> where '2005-10-25 15:00:00' <= when_stopped
>and when_stopped <= '2005-10-26 10:00:00'
> union all
> selectwhen_stopped as when_happened,
>
26 matches
Mail list logo
