""Magnus Hagander"" <[EMAIL PROTECTED]> wrote
>>
>> 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
>> differe
""Merlin Moncure"" <[EMAIL PROTECTED]> wrote
> ok, here is gprof output from newlines/no newlines
> [newlines]
> % cumulative self self total
> time seconds secondscalls s/call s/call name
> 19.03 0.67 0.671 0.67 3.20 MainLoop
> 17.61
> >> AFAICS it is appropriate to move the sigsetjmp and
> >> setup_cancel_handler calls in front of the per-line loop inside
> >> MainLoop --- can anyone see a reason not to?
>
> > hm. mainloop is re-entrant, right? That means each \i
> would reset the
> > handler...what is downside to keepin
> > I'm inclined to treat this as an outright bug, not just a minor
> certainly...
>
> > performance issue, because it implies that a sufficiently long psql
> > script would probably crash a Windows machine.
>
> actually, it's worse than that, it's more of a dos on the
> whole system, as window
David Fetter wrote:
> On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
> > "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > > Nailed it.
> >
> > > problem is in mainloop.c -> setup_cancel_handler. Apparently you
> > > can have multiple handlers and windows keeps track of them all,
> > >
David Fetter <[EMAIL PROTECTED]> writes:
> On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
>> I'm inclined to treat this as an outright bug, not just a minor
>> performance issue, because it implies that a sufficiently long psql
>> script would probably crash a Windows machine.
> Ouch.
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Nailed it.
>
> > problem is in mainloop.c -> setup_cancel_handler. Apparently you can
> > have multiple handlers and windows keeps track of them all, even if they
> > do the same thing. Keeping track of so many system handles wou
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> AFAICS it is appropriate to move the sigsetjmp and
>> setup_cancel_handler
>> calls in front of the per-line loop inside MainLoop --- can anyone see
>> a reason not to?
> hm. mainloop is re-entrant, right? That means each \i would reset the
> handle
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Nailed it.
>
> > problem is in mainloop.c -> setup_cancel_handler. Apparently you
can
> > have multiple handlers and windows keeps track of them all, even if
they
> > do the same thing. Keeping track of so many system handles would
> > naturally
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Nailed it.
> problem is in mainloop.c -> setup_cancel_handler. Apparently you can
> have multiple handlers and windows keeps track of them all, even if they
> do the same thing. Keeping track of so many system handles would
> naturally slow the whol
Nailed it.
problem is in mainloop.c -> setup_cancel_handler. Apparently you can
have multiple handlers and windows keeps track of them all, even if they
do the same thing. Keeping track of so many system handles would
naturally slow the whole process down. Commenting that line times are
flat as
Michal Taborsky <[EMAIL PROTECTED]> writes:
> OK. Mystery (sort of) solved. After you told me it works for you I had
> to assume the problem was somewhere else. And, indeed, it was, though
> it's not too obvious.
> The two attributes are actually not of tybe bigint, but of type
> "crm_object_id
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ok, mingw gprof is claiming MainLoop is a culprit here,
The only thing I can see that would be different for Windows is the
SetConsoleCtrlHandler kernel call ... could that be expensive? Why
do we have either sigsetjmp or setup_cancel_handler inside
ok, here is gprof output from newlines/no newlines
[newlines]
% cumulative self self total
time seconds secondscalls s/call s/call name
19.03 0.67 0.671 0.67 3.20 MainLoop
17.61 1.29 0.62 500031 0.00
Tom Lane napsal(a):
Michal Taborsky <[EMAIL PROTECTED]> writes:
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
Perhaps you should show us the real schema, because I cannot duplicate
your complaint on the toy case you
>
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > yeah. I'm guessing problem is in the mingw flex/bison (which I
really,
> > really hope is not the case) or some other win32 specific block of
code.
> > I'm snooping around there...
>
> Maybe I'm confused here, but I thought we had established
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> yeah. I'm guessing problem is in the mingw flex/bison (which I really,
> really hope is not the case) or some other win32 specific block of code.
> I'm snooping around there...
Maybe I'm confused here, but I thought we had established that the local
Michal Taborsky <[EMAIL PROTECTED]> writes:
> We are facing a performance problem with views consisting of several
> unioned tables. The simplified schema is as follows:
Perhaps you should show us the real schema, because I cannot duplicate
your complaint on the toy case you show.
regression=# e
> That's bizarre ... I'd have thought a very long line would be more
> likely to trigger internal performance problems than the original.
>
> What happens if you read the file with "psql -f dump.sql" instead
> of cat/stdin?
non-flat. Also ran via \i and got non flat times.
> BTW, I get flat tim
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> It doesn't, and it doesn't. :/ Ok, here's where it gets interesting. I
> removed all the newlines from the test output (dump.sql) and got flat
> times ;).
That's bizarre ... I'd have thought a very long line would be more
likely to trigger internal
On Fri, Nov 04, 2005 at 12:38:30PM +0100, Michal Taborsky wrote:
> SELECT object_id FROM commonview WHERE link_id=1234567
>
> The result is sequential scan on all tables, append, sort and then
> filter scan on this whole thing. Which of course is slow as hell. We use
> version 8.0.2.
I couldn't
> > not quite: attached is a file to generate test.
>
> > cat dump.sql | psql -q yadda
>
> Ah. Does your psql have readline support? if so, does adding -n to
> that command change anything?
>
It doesn't, and it doesn't. :/ Ok, here's where it gets interesting. I
removed all the newlines fr
> Hello everyone.
>
> We are facing a performance problem with views consisting of several
> unioned tables. The simplified schema is as follows:
>
> CREATE TABLE foo (
> foo_object_id bigint,
> link_id bigint,
> somedatatext,
> PRIMARY KEY (foo_object_id
Michal Taborsky wrote:
...
UNION
...
The result is sequential scan on all tables, append, sort and then
filter scan on this whole thing. Which of course is slow as hell. We use
version 8.0.2.
And now the question: Is there a way to force the planner to push the
condition lower, so it will u
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> You mean something like the attached?
> not quite: attached is a file to generate test.
> cat dump.sql | psql -q yadda
Ah. Does your psql have readline support? if so, does adding -n to
that command change anything?
reg
Hello everyone.
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
CREATE TABLE foo (
foo_object_id bigint,
link_id bigint,
somedatatext,
PRIMARY KEY (foo_object_id) );
CRE
> > You mean something like the attached?
oh, btw I ran timeit.c and performance is flat and fairly fast. I'm
pretty sure psql is the culprit here.
Merlin
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
> You mean something like the attached?
not quite: attached is a file to generate test.
to do it:
psql yadda
\i timeit.sql
\t
\o dump.sql
select make_dump(5, false);
\q
cat dump.sql | psql -q yadda
and see what pops out. I had to do it that way because redirecting psql
to dump file caused
28 matches
Mail list logo
