473,889 Members | 1,734 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

website doc search is extremely SLOW

Trying to use the 'search' in the docs section of PostgreSQL.org
is extremely SLOW. Considering this is a website for a database
and databases are supposed to be good for indexing content, I'd
expect a much faster performance.

I submitted my search over two minutes ago. I just finished this
email to the list. The results have still not come back. I only
searched for:

SECURITY INVOKER

Perhaps this should be worked on?

Dante

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05
83 5992
On Thu, 1 Jan 2004, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
'k, and for todays question ... how does one 'knock up the stats target'?


ALTER TABLE [ ONLY ] name [ * ]
ALTER [ COLUMN ] column SET STATISTICS integer

The default is 10; try 100, or even 1000 (don't think it will let you
go higher than 1000).


k, so:

186_archives=# alter table ndict8 alter column word_id set statistics 1000;
ALTER TABLE

followed by an 'vacuum verbose analyze ndict8', which showed an analyze
of:

INFO: analyzing "public.ndi ct8"
INFO: "ndict8": 34718 pages, 300000 rows sampled, 6354814 estimated total rows

vs when set at 10:

INFO: analyzing "public.ndi ct8"
INFO: "ndict8": 34718 pages, 3000 rows sampled, 6229711 estimated total rows

The query @ 1000:

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=13918.23. .76761.02 rows=81 width=8) (actual time=5199.443.. 5835.444 rows=13415 loops=1)
Hash Cond: ("outer".url _id = "inner".rec _id)
-> Index Scan using n8_word on ndict8 (cost=0.00..627 61.60 rows=16075 width=8) (actual time=0.230..344 .485 rows=15533 loops=1)
Index Cond: (word_id = 417851441)
-> Hash (cost=13913.31. .13913.31 rows=1968 width=4) (actual time=5198.289.. 5198.289 rows=0 loops=1)
-> Seq Scan on url (cost=0.00..139 13.31 rows=1968 width=4) (actual time=3.933..341 4.657 rows=304811 loops=1)
Filter: ((url || ''::text) ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 5908.778 ms
(8 rows)

Same query @ 10:

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=13918.23. .26502.18 rows=17 width=8) (actual time=3657.984.. 4293.529 rows=13415 loops=1)
Hash Cond: ("outer".url _id = "inner".rec _id)
-> Index Scan using n8_word on ndict8 (cost=0.00..125 67.73 rows=3210 width=8) (actual time=0.239..362 .375 rows=15533 loops=1)
Index Cond: (word_id = 417851441)
-> Hash (cost=13913.31. .13913.31 rows=1968 width=4) (actual time=3657.480.. 3657.480 rows=0 loops=1)
-> Seq Scan on url (cost=0.00..139 13.31 rows=1968 width=4) (actual time=2.646..216 6.632 rows=304811 loops=1)
Filter: ((url || ''::text) ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 4362.375 ms
(8 rows)

I don't see a difference between the two, other then time changes, but
that could just be that runA had a server a bit more idle then runB ...
something I'm not seeing here?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

Nov 12 '05 #41
Marc G. Fournier wrote:
On Thu, 1 Jan 2004, Arjen van der Meijden wrote:

Marc G. Fournier wrote:
Now, if I knock off the LIKE, so that I'm returning all rows from ndict8,
join'd to all the URLs that contain them, you get:
Can't you build seperate databases for each domain you want to index?
Than you wouldn't need the like operator at all.

First off, that would make searching across multiple domains difficult,
no?

If mnogosearch would allow searching in multiple databases; no. But it
doesn't seem to feature that and indeed; yes that might become a bit
difficult.
It was something I thought of because our solution allows it, but that
is no solution for you, I checked the mnogosearch features after sending
that email, instead of before. Perhaps I should've turned that around.
Second, the LIKE is still required ... the LIKE allows the search to
"group" URLs ... for instance, if I wanted to just search on the docs, the
LIKE would look for all URLs that contain:

http://www.postgresql.org/docs/%%

whereas searching the whole site would be:

http://www.postgresql.org/%%

That depends. If it were possible, you could decide from the search
usage stats to split /docs from the "the rest" of www.postgresql.org and
by that avoiding quite a bit of like's.
Anyway, that doesn't help you much, perhaps decreasing the size of the
index-tables can help, are they with OIDs ? If so, wouldn't it help to
recreate them without, so you save yourselves 4 bytes per word-document
couple, therefore allowing it to fit in less pages and by that speeding
up the seqscans.

This one I hadn't thought about ... for some reason, I thought that
WITHOUT OIDs was now the default ... looking at that one now ...

No, it's still the default to do it with oids.
By the way, can a construction like (tablefield || '') ever use an index
in postgresql?

again, as shown in a previous email, the index is being used for the LIKE
query ... the big problem as I see it is that the result set from the LIKE
is ~20x larger then the result set for the the = ... if there was some way
to telling the planner that going the LIKE route was the more expensive of
the two (even though table size seems to indicate the other way around), I
suspect that that would improve things also ...

Yeah, I noticed. Hopefully Tom's suggestion will work to achieve that.

I can imagine how you feel about all this, I had to do a similar job a
year ago, but was less restricted by a preference like the "it'd be a
nice postgresql showcase". But then again, our search engine is loaded
with an average of 24 queries per minute (peaking to over 100/m in the
afternoon and evenings) and we didn't have any working solution (not
even a slow one).

Good luck,

Arjen van der Meijden

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #42
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
I don't see a difference between the two, other then time changes, but
that could just be that runA had a server a bit more idle then runB ...
something I'm not seeing here?


Well, the difference I was hoping for was a more accurate rows estimate
for the indexscan, which indeed we got (estimate went from 3210 to
16075, vs reality of 15533). But it didn't change the plan :-(.

Looking more closely, I see the rows estimate for the seqscan on "url"
is pretty awful too (1968 vs reality of 304811). I think it would get
better if you were doing just
AND (url.url LIKE 'http://archives.postgr esql.org/%%');
without the concatenation of an empty string. Is there a reason for the
concatenation part of the expression?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #43
On Thu, 1 Jan 2004, Arjen van der Meijden wrote:
That depends. If it were possible, you could decide from the search
usage stats to split /docs from the "the rest" of www.postgresql.org and
by that avoiding quite a bit of like's.


then what if you want to search:

http://www.postgresql.org/docs/7.4/%%

vs

http://www.postgresql.org/docs/7.3/%%

:)

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #44
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
The full first query: SELECT ndict8.url_id,n dict8.intag
FROM ndict8, url
WHERE ndict8.word_id= 417851441
AND url.rec_id=ndic t8.url_id
AND ((url.url || '') LIKE 'http://archives.postgr esql.org/%%'); returns 13415 rows, and explain analyze shows: Nested Loop (cost=0.00..301 99.82 rows=17 width=8) (actual time=0.312..145 9.504 rows=13415 loops=1)
-> Index Scan using n8_word on ndict8 (cost=0.00..126 16.09 rows=3219 width=8) (actual time=0.186..387 .673 rows=15532 loops=1)
Index Cond: (word_id = 417851441)
-> Index Scan using url_rec_id on url (cost=0.00..5.4 5 rows=1 width=4) (actual time=0.029..0.0 50 rows=1 loops=15532)
Index Cond: (url.rec_id = "outer".url _id)
Filter: ((url || ''::text) ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 1520.145 ms
(7 rows)


The more I look at it, the more it seems that this is the best plan for
the query. Since the URL condition is very unselective (and will
probably be so in most all variants of this query), it just doesn't pay
to try to apply it before doing the join. What we want is to make the
join happen quickly, and not even bother applying the URL test until
after we have a joinable url entry.

(In the back of my mind here is the knowledge that mnogosearch is
optimized for mysql, which is too stupid to do the query in any way
other than a plan like the above.)

I think Bruce's original suggestion of clustering was right on, except
he guessed wrong about what to cluster. The slow part is the scan on
ndict8, as we saw in the later message:

-> Index Scan using n8_word on ndict8 (cost=0.00..126 16.09 rows=3219 width=8) (actual time=113.645..7 9163.431 rows=15533 loops=1)
Index Cond: (word_id = 417851441)

Presumably, the first EXPLAIN shows the behavior when this portion of
ndict8 and its index have been cached, while the second EXPLAIN shows
what happens when they're not in cache. So my suggestion is to CLUSTER
ndict8 on n8_word. It might also help to CLUSTER url on url_rec_id.
Make sure the plan goes back to the nested indexscan as above (you might
need to undo the statistics-target changes).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #45
On Thu, 1 Jan 2004, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
I don't see a difference between the two, other then time changes, but
that could just be that runA had a server a bit more idle then runB ...
something I'm not seeing here?


Well, the difference I was hoping for was a more accurate rows estimate
for the indexscan, which indeed we got (estimate went from 3210 to
16075, vs reality of 15533). But it didn't change the plan :-(.

Looking more closely, I see the rows estimate for the seqscan on "url"
is pretty awful too (1968 vs reality of 304811). I think it would get
better if you were doing just
AND (url.url LIKE 'http://archives.postgr esql.org/%%');
without the concatenation of an empty string. Is there a reason for the
concatenation part of the expression?


Believe it or not, the concatenation was based on a discussion *way* back
(2 years, maybe?) when we first started using Mnogosearch, in which you
suggested going that route ... in fact, at the time (bear in mind, this is
back in 7.2 days), it actually sped things up ...

Ok, with statistics set to 10, we now have:

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.00..316 72.49 rows=1927 width=8) (actual time=117.064..5 4476.806 rows=13415 loops=1)
-> Index Scan using n8_word on ndict8 (cost=0.00..125 67.73 rows=3210 width=8) (actual time=80.230..47 844.752 rows=15533 loops=1)
Index Cond: (word_id = 417851441)
-> Index Scan using url_rec_id on url (cost=0.00..5.9 4 rows=1 width=4) (actual time=0.392..0.3 98 rows=1 loops=15533)
Index Cond: (url.rec_id = "outer".url _id)
Filter: (url ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 54555.011 ms
(7 rows)

And, at 1000 (and appropriate vacuum analyze on ndict8):

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
Merge Join (cost=91613.33. .92959.41 rows=9026 width=8) (actual time=12834.316. .16726.018 rows=13415 loops=1)
Merge Cond: ("outer".url _id = "inner".rec _id)
-> Sort (cost=59770.57. .59808.18 rows=15043 width=8) (actual time=776.823..8 49.798 rows=15533 loops=1)
Sort Key: ndict8.url_id
-> Index Scan using n8_word on ndict8 (cost=0.00..587 26.82 rows=15043 width=8) (actual time=0.296..680 .139 rows=15533 loops=1)
Index Cond: (word_id = 417851441)
-> Sort (cost=31842.76. .32433.09 rows=236133 width=4) (actual time=12056.594. .14159.852 rows=311731 loops=1)
Sort Key: url.rec_id
-> Index Scan using url_url on url (cost=0.00..107 68.79 rows=236133 width=4) (actual time=225.243..8 353.024 rows=304811 loops=1)
Index Cond: ((url >= 'http://archives.postgr esql.org/'::text) AND (url < 'http://archives.postgr esql.org0'::tex t))
Filter: (url ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 16796.932 ms
(12 rows)

Closer to what you were looking/hoping for?

Second run, @1000, shows:

Total runtime: 12194.016 ms
(12 rows)

Second run, after knocking her back down to 10, shows:

Total runtime: 58119.150 ms
(7 rows)

so we're definitely improved ... if this is the kinda results you were
hoping to see, then I guess next step would be to increase/reanalyze all
the word_id columns ... what about the url.url column? should that be
done as well? what does that setting affect, *just* the time it takes to
analyze the table? from the verbose output, it looks like it is scanning
more rows on an analyze then @ 10 ... is this something that can be set
database wide, before loading data? and/or something that the default is
currently just too low?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #46
On Thu, 1 Jan 2004, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
The full first query:

SELECT ndict8.url_id,n dict8.intag
FROM ndict8, url
WHERE ndict8.word_id= 417851441
AND url.rec_id=ndic t8.url_id
AND ((url.url || '') LIKE 'http://archives.postgr esql.org/%%');

returns 13415 rows, and explain analyze shows:

Nested Loop (cost=0.00..301 99.82 rows=17 width=8) (actual time=0.312..145 9.504 rows=13415 loops=1)
-> Index Scan using n8_word on ndict8 (cost=0.00..126 16.09 rows=3219 width=8) (actual time=0.186..387 .673 rows=15532 loops=1)
Index Cond: (word_id = 417851441)
-> Index Scan using url_rec_id on url (cost=0.00..5.4 5 rows=1 width=4) (actual time=0.029..0.0 50 rows=1 loops=15532)
Index Cond: (url.rec_id = "outer".url _id)
Filter: ((url || ''::text) ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 1520.145 ms
(7 rows)


The more I look at it, the more it seems that this is the best plan for
the query. Since the URL condition is very unselective (and will
probably be so in most all variants of this query), it just doesn't pay
to try to apply it before doing the join. What we want is to make the
join happen quickly, and not even bother applying the URL test until
after we have a joinable url entry.

(In the back of my mind here is the knowledge that mnogosearch is
optimized for mysql, which is too stupid to do the query in any way
other than a plan like the above.)

I think Bruce's original suggestion of clustering was right on, except
he guessed wrong about what to cluster. The slow part is the scan on
ndict8, as we saw in the later message:

-> Index Scan using n8_word on ndict8 (cost=0.00..126 16.09 rows=3219 width=8) (actual time=113.645..7 9163.431 rows=15533 loops=1)
Index Cond: (word_id = 417851441)

Presumably, the first EXPLAIN shows the behavior when this portion of
ndict8 and its index have been cached, while the second EXPLAIN shows
what happens when they're not in cache. So my suggestion is to CLUSTER
ndict8 on n8_word. It might also help to CLUSTER url on url_rec_id.
Make sure the plan goes back to the nested indexscan as above (you might
need to undo the statistics-target changes).


k, so return statistics to the default, and run a CLUSTER on n8_word and
url_rec_id ... now, question I asked previously, but I think Bruce might
have overlooked it ...

what sort of impact does CLUSTER have on the system? For instance, an
index happens nightly, so I'm guessing that I'll have to CLUSTER each
right after? Will successive CLUSTERs take less time then the initial
one? I'm guessing so, since the initial one will have 100% to sort, while
subsequent ones will have a smaller set to work with, but figured I'd ask
.... from the man page, all I figure I need to do (other then the initial
time) is:

VACUUM;
CLUSTER;

With 7.4, VACUUM full isn't a requirement, but is it if I'm going to do a
CLUSTER after?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #47
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
On Thu, 1 Jan 2004, Tom Lane wrote:
Is there a reason for the
concatenation part of the expression?
Believe it or not, the concatenation was based on a discussion *way* back
(2 years, maybe?) when we first started using Mnogosearch, in which you
suggested going that route ... in fact, at the time (bear in mind, this is
back in 7.2 days), it actually sped things up ...
Hmm, I vaguely remember that ... I think we were deliberately trying to
fool the planner at that time, because it was making some stupid
assumption about the selectivity of the LIKE clause. It looks like that
problem is now mostly fixed, since your second example shows estimate of
236133 vs reality of 304811 rows for the URL condition:
-> Index Scan using url_url on url (cost=0.00..107 68.79 rows=236133 width=4) (actual time=225.243..8 353.024 rows=304811 loops=1)
Index Cond: ((url >= 'http://archives.postgr esql.org/'::text) AND (url < 'http://archives.postgr esql.org0'::tex t))
Filter: (url ~~ 'http://archives.postgr esql.org/%%'::text)
Total runtime: 16796.932 ms
(12 rows) Closer to what you were looking/hoping for?
This probably says that we can stop using the concatenation hack, at
least. I'd still suggest clustering the two tables as per my later
message. (Note that clustering would help this mergejoin plan too,
so it could come out to be a win relative to the nestloop indexscan,
but we ought to try both and see.)
what does that setting affect, *just* the time it takes to
analyze the table?
Well, it will also bloat pg_statistic and slow down planning a little.
Can you try 100 and see if that gives reasonable estimates? 1000 is a
rather extreme setting I think; I'd go for 100 to start with.
is this something that can be set database wide,


Yeah, see default_statist ics_target in postgresql.conf .

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #48
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
what sort of impact does CLUSTER have on the system? For instance, an
index happens nightly, so I'm guessing that I'll have to CLUSTER each
right after?


Depends; what does the "index" process do --- are ndict8 and friends
rebuilt from scratch?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #49
On Thu, 1 Jan 2004, Tom Lane wrote:
"Marc G. Fournier" <sc*****@postgr esql.org> writes:
what sort of impact does CLUSTER have on the system? For instance, an
index happens nightly, so I'm guessing that I'll have to CLUSTER each
right after?


Depends; what does the "index" process do --- are ndict8 and friends
rebuilt from scratch?


nope, but heavily updated ... basically, the indexer looks at url for what
urls need to be 're-indexed' ... if it does, it removed all words from the
ndict# tables that belong to that url, and re-adds accordingly ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
2239
by: bettina | last post by:
I'm re-programming my Website (www.coaster.ch) in PHP and I find it too slow (although I have ADSL). That's more or less how it functions: Here my tables: 'COASTERS' (code of coaster, code of country, etc...) 'COUNTRIES' (code of country, names of countries in different languages, code of continent) 'CONTINENTS' (code of continent, names of continents in different languages)
12
6490
by: Vjay77 | last post by:
Hi, I haven't posted any problem in quite a while now, but I came to the point that I really need to ask for help. I need to create an application which will search through .txt log file and find all lines where email from hotmail occured. All these emails need to be printed to list box on the form. Problem with code you'll see below, is that it takes long time to
4
4779
by: sommes | last post by:
It's only happen on .asp website, what's the problem? Thank you
2
2080
by: tmb | last post by:
When publishing a website the process is excrutiatingly slow - we are talking 3-4 minutes from when the actual transfer to the site has begun to completion. Apparently i'm not the only one experiencing this and searching on the net i found a possible solution: http://blog.n-technologies.be/CommentView.aspx?guid=3df1930b-9517-4b9b-9dd6-b59cbcbbe34d However, i don't quite understand how to actually apply the solution mentioned. I have...
2
5043
by: yasmike | last post by:
I am having a problem with my secure website on our internal network. The secure website is hosted on our Windows 2000 Server running IIS 5.0. If you try and access the website from a browser from another computer on the same internal network using its domain name, https://www.domainname .com, it is extremely slow. If you access it using its IP https://192.168.1.2 it is very quick. It is also quick for anyone outside the internal network to...
0
9967
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9810
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11202
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
10895
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10443
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7998
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6029
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4650
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4251
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.