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,
2 as
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 ||
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 ' ||
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 (
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 not sure
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
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 two
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
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
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:
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
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.
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
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 already do that, don't we?
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
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
that will
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. Initial time is
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
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 internal
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 macro?
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:
First
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 a winxp
22 matches
Mail list logo
