Mark Mielke wrote:
Kless wrote:
The new data type, UUID, is stored as a string -char(16)-:
struct pg_uuid_t
{
unsigned char data[UUID_LEN];
};
#define UUID_LEN 16
What is the complaint? Do you have evidence that it would be
noticeably faster as two 64-bits? Note that a UUID
Mark Mielke wrote:
I didn't notice that he put 16. Now I'm looking at uuid.c in
PostgreSQL 8.3.3 and I see that it does use 16, and the struct
pg_uuid_t is length 16. I find myself confused now - why does
PostgreSQL define UUID_LEN as 16?
I will investigate if I have time tonight. There MUST
platforms. Windows 64 seems as if it may continue to be as popular as
Windows 32, and should probably be supported.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
...
At the very least we have some more information on how an eventual
solution should work, and a test case to help analyse the effectiveness
of any potential solution.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via
Gregory Stark wrote:
Well at least it caught the bug that Mark was performance testing with a
--enable-cassert build :/
True ;) I appreciated that there would be some overhead, but I didn't
think it would be that much. This was mainly since I seem to remember
there was talk a while back
size that will never extend beyond 1
Gb as it is likely to perform the best.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on geography (cost=0.00..7092.00 rows=1 width=0)
(actual time=55.016..9073.084 rows=32880 loops=1)
Filter: (centroid $0)
Total runtime: 9117.174 ms
(7 rows)
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
if this is present.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, if it were to say an alternative form of ELSEIF is to nest IF
statement like so: ...
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
assigning into a varchar(8) for example).
The problem here seems to that point should have an equality operator?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
presume most of this information
normally easily fits in cache most of the time?
I am trying to understand what exactly it is worth... :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
that be
determined by re-checking the table row after querying it?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
, VARSIZE_EXTERNAL(pgl));
PG_RETURN_POINTER(mem);
}
...and of course, this now takes the slower runtime of 2.5s.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers
converted to its bounding box (which would not require deTOASTing)
before being used as an index scan key.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers
doesn't seem to want to run at the moment
:( I'm wondering if it's related to either excess TOAST/palloc/pfree
somewhere in the code, but I'd definitely appreciate any pointers.
All these tests were done using PostgreSQL 8.3.1 and the latest PostGIS SVN.
Many thanks,
Mark.
--
Mark Cave-Ayland
geography_geom_centroid_idx on geography
(cost=0.00..8.28 rows=1 width=0) (actual time=43.218..286.535 rows=32880
loops=1)
Index Cond: (centroid ($0)::geometry)
Filter: (centroid ($0)::geometry)
Total runtime: 376.117 ms
(8 rows)
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open
in the coordinate sequence, but
nothing major. I've removed the -VARHDRSZ part just to check and it
doesn't make any difference.
Many thanks,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list
numerical analysis courses at university) SUM and
ROUND can *never* be commuted. In general the recommended approach is to
round as late as possible and as few times are possible - so your 1st
query is the correct or best way to go.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql
recursion. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
I am using PostgreSQL's SSL support and the conventions for the key and
certifications don't make sense from the client perspective. Especially
under Windows.
I am proposing a few simple changes:
Adding two API
void PQsetSSLUserCertFileName(char *filename)
{
user_crt_filename =
and product_image_archived
tables, is that product_image has a primary key constraint on the
product identifier.
I can do it the original way - it just seemed odd.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
the most benefit.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, with 0 chance of collision. This extreme defeats the
purpose of a hash to start with.
Why does PostgreSQL need something better than md5 as part of core?
Bragging rights?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Svenne Krap wrote:
Mark Mielke wrote:
This presumes that better hashes truly exist. It is basic math to
show that all hashes will include collisions. Ignoring the
possibility that one hash has theoretical better distribution for
real documents, the real benefit of SHA-1 over MD5
ending
infinite resource trap. More is not better. Better is better. If you can
prove md5 is insufficient for PostgreSQL passwords, the correct decision
would be to switch to something better, and deprecate md5 from the core.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql
needed to do that.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, and becomes
very interesting.
In my current db project, I never count all of the rows in a table.
However, I do use count(*) with GROUP BY and WHERE.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
forks might be used for, and (b) the name fails to be
inclusive of the data fork. Other suggestions anyone?
I believe that in the world of NTFS the concept is called streams:
http://support.microsoft.com/kb/105763.
HTH,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
? :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
the assumption that because they can
get counts faster from other databases, therefore PostgreSQL should do
it as well. I sometimes wonder whether these people would even notice if
PostgreSQL translated count(*) on the whole table to query reltuples. :-)
Cheers,
mark
--
Mark Mielke [EMAIL
Pavan Deolasee wrote:
On Wed, Mar 12, 2008 at 9:14 PM, Mark Mielke [EMAIL PROTECTED] wrote:
If you are talking about automatically doing this for every table - I
have an objection that the performance impact seems unwarranted against
the gain. We are still talking about every insert
Pavan Deolasee wrote:
On Wed, Mar 12, 2008 at 9:53 PM, Mark Mielke [EMAIL PROTECTED] wrote:
Fine - once per transaction instead of once per insert. Still, if there is
overhead to this (updating a secondary summary table), does it really make
sense to have it for every table? Most of my
- 24 months. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
mark
--
Mark Mielke [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Mark Mielke [EMAIL PROTECTED] writes:
... I think the transaction overhead, and
attempts to re-use PostgreSQL tables to implement LISTEN/NOTIFY to be
clever but mis-guided.
Oh, I don't disagree with you. As I already mentioned, they desperately
need to be rewritten
for PostgreSQL to
support all formats, not matter how non-standard, for every single type.
So, why would UUID be special? Because it's easy to do is not
necessarily a good reason. But then, it's not a bad reason either.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end
James Mansion wrote:
Mark Mielke wrote:
I recall there being a measurable performance difference between the
most liberal parser, and the most optimized parser, back when I wrote
one for PostgreSQL. I don't know how good the one in use for
PostgreSQL 8.3 is. As to whether the cost
the insert ... select. I thought the above would
be a clever PostgreSQL-8.3 alternative, but I'm either stupid or it
doesn't work... :-)
Any ideas?
Thanks,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9
table is
now 1/3 the number of relpages in 8.3 as it was in 8.2. Good job all
around hackers. Again - *NO* problems. It just works.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
I have been looking at this thread for a bit and want to interject an idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of a configuration file from
Mark Woodward wrote:
I have been looking at this thread for a bit and want to interject an
idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion
.
Cheers,
mark
P.S. Depending on configuration, it might be 'git pull'.
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: explain analyze is your friend
less
time than having to wait for someone like Alvaro or Tom to review and commit
several hundred KB of code.
This seems to fit more with the idea of a distributed SCM, although it
wouldn't be entirely out of the question to set up permissions using CVS/SVN.
ATB,
Mark.
--
Mark Cave-Ayland
think time to install
from source is a legitimate concern. Installing from source is great,
but if the package needs to be installed from source, it is not well
enough supported by the community to be worth using.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Tom Lane wrote:
Mark Mielke [EMAIL PROTECTED] writes:
In terms of picking an SCM candidate, I don't think time to install
from source is a legitimate concern. Installing from source is great,
but if the package needs to be installed from source, it is not well
enough supported
Mark Mielke wrote:
Perhaps he didn't read the instructions. See below for a 5 minutes 34
elapsed time. This includes extracting SVN over the network using SVN.
And just to be complete, here is git at 2 minutes 13 seconds. Not that
these times matter at all, but in case anybody thinks they do
didn't read the instructions. See below for a 5 minutes 34
elapsed time. This includes extracting SVN over the network using SVN.
Cheers,
mark
$ time zsh
$ svn checkout http://svn.collab.net/repos/svn/trunk svn-devel
...
Checked out revision 29228.
$ cd svn-devel
$ ./autogen.sh
...
You can run
existing
mirror technology to have their way, and the side with the most
resources will win and have their way in the end. One hopes for an
overall improvement. :-)
Haha - that's my opinion.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast
partitions. It could be that it doesn't.
Regards,
Mark
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
for PostgreSQL. I would like to experiment with Hg
and a few others over the next few months and see what I think of these.
I encourage all to keep their minds open.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
zero effect on the code,
however it may be worth applying for correctness and consistency with
other platform implementations.
ATB,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
/*
* rint() test program
*
* Compile on gcc using:
* gcc -o test test.c -lm
*/
#include
of the day, if it doesn't have any real
effect then there is no need to worry about it.
ATB,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 4: Have you searched our list archives
shoulder.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
FYI: I don't like being attacked for stating the truth, nor distracting
the mailing list with these emotional discussions. However, there are
things that need to be clarified. Feel free to kill the thread in your
mail browser.
James Mansion wrote:
Mark Mielke wrote:
Joshua D. Drake wrote
are requesting, but
I suggest that is where you are leading.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
*before* Oracle would listen to me)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
yourself?
If it was so easy, and such a clear win, I think one of the very
competent people using PostgreSQL today would have already done it?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: You can help support
Mark Mielke wrote:
Counts, because as we all know, PostgreSQL count(*) is slow, and in
any case, my count(*) is not on the whole table, but on a subset.
Doing this in a general way seems complex to me as it would need to be
able to evaluate whether a given INSERT or UPDATE or one
Dave Page wrote:
On 12/01/2008, Mark Mielke [EMAIL PROTECTED] wrote:
Jean-Michel Pouré wrote:
In my past development projects, I always used the concept of
Materialized VIEW to speed-up SELECTs over INSERTs
Unless you are going to *pay* for it - you do realize that the best way
not think it is as easy as you say - but
feel free to continue the discussion and prove how idiotic I am for
calling the problem not easy. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
don't see how dynamic in-table partitioning
handles this, and I think it would highly desirable to be able to do
these things!
best wishes
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
authentication and encrypted data stream cost is high compared to no
cryptographic authentication or encrypted data streams. I don't know if
it would impact me or not. Peter: Have you tried running a benchmark of
localssl vs localnossl?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Magnus Hagander wrote:
Mark Mielke wrote:
Why are you even using a password in this case, and not just key-based
auth? Wouldn't that be even easier and more secure?
Users of this product don't have keys - they have passwords. The
username/password is for per-user authentication
. This is
where your first answer of running PostgreSQL on a machine with trusted
users comes in as a sensible recommendation, even if only some people
are willing to accept this recommendation. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast
required.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Magnus Hagander wrote:
Mark Mielke wrote:
I have done this for my own application before. Although the client and
server use standard TLS 1.0 to speak to each other with a required
authentication of RSA 1024-bit and a required encryption of AES 128-bit,
it still requires that passwords sent
and accurate as the claim you make
above, it may be irrelevant in many real world scenarios. If you are
going to go through all the expensive processing of having
authentication enabled, you may as well have encryption enabled too.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED
.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
overhead is minimal compared to the
overhead of authentication. For these reasons NULL ciphers are not
recommended.
Looks good!
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free
I did, but booleans stopped working for exactly
this reason (where they did work in the past). For lack of time or care,
my PHP now has added === 't' ? true : false in various places... :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast
Gregory Stark wrote:
Mark Mielke [EMAIL PROTECTED] writes:
UNIX socket kernel credential passing was mentioned in an earlier post, but I
didn't see it raised again.
I mentioned getsockopt(SO_PEERCRED) which isn't the same as credential
passing. It just tells you what uid
Bruce Momjian wrote:
Mark Mielke wrote:
I agree - I forgot there were different flavours. I think any of these
are just as good as SSL with public key authentication, and perhaps a
lot cheaper in terms of performance. The only piece of information
missing is the uid to compare against
be usable in reverse? I've seen many people claim identd is
insecure - but it is secure if I am the one running it, is it not?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
to a machine at the data center to
solve the problem. Self healing is a term that is used to describe
approaches such as this.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Jeff Davis wrote:
On Wed, 2007-12-19 at 15:51 -0500, Mark Mielke wrote:
That sounds possible, but I still feel myself suspecting that disk
reads will be much slower than localized text comparison. Perhaps I am
overestimating the performance of the comparison function?
I think
multiple execution units (whether CPUs, cores, or HT).
It's interesting discussion for me thus far.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
increases.
Or do you mean being able to perform parts of the query plan fully in
parallel? If this, then one would need a lot more than ParallelSort...
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked
, sorting)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
that would be
easier to isolate.
Also a good point. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Jeff Davis wrote:
On Wed, 2007-12-19 at 12:08 -0500, Mark Mielke wrote:
Stupid question #2: Is it well recognized that the CPU is the
bottleneck in the PostgreSQL sorting mechanism? Or might it be memory
bandwidth and I/O?
I think it depends a lot on several factors. It's probably
other suggestion I can think of at the moment would be
PQconnectionUsedConnectionPassword which seems to better sum up its
purpose to me...
Kind regards,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast
concern is the switch from a
non-interactive mode to an interactive mode.
Kind regards,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
deeper.
Many thanks,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
:(
Is there an additional status code in PGconn that can be used to
determine the exact cause of connection failure?
ATB,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 6: explain analyze is your friend
the
*compressed* size.)
Cheers
Mark
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
it would have on
typical queries and on special queries like Matthew's. Are you able to
tweak the index scan and bitmap scan methods to do posfix_fadvise()
before running? Even if it doesn't do anything more intelligent such as
you described in another post?
Cheers,
mark
--
Mark Mielke [EMAIL
to PostgreSQL 8.0 - can anyone think of any better ideas?
Many thanks,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 6: explain analyze is your friend
this down to user error - thanks for the
advice Tom.
Many thanks,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
the former is supposed to hold
architecture-dependent files and the latter architecture-independent
files.
Mark hasn't been very clear about whether he wants to store static data
files or installation-changeable configuration info, so it's not clear
to me whether Peter's objection to using
.
For the future, please consider doing integer division when working with
integers and the rvalue is a constant. For this case, it doesn't seem
like it is worth it to risk breaking the code.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
. My memory
is faint, but I think SPARC v7 either implemented / in software, or had
a trap that implemented it in software.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
benefits.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
calculation calculating aggregates
and fields with conditional values. The ACCPAC query based entirely on a
view takes over 1 second to run. The query on the materialized view
row takes 0.01 seconds. Quite a difference. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
On Tue, 06 Nov 2007 13:15:02 +
Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2007-11-05 at 14:33 -0800, Mark Wong wrote:
On 11/4/07, Simon Riggs [EMAIL PROTECTED] wrote:
Why don't you post a TODO list for TPC-E somewhere, so people can bite
small pieces off of the list. I'm sure
On 11/4/07, Simon Riggs [EMAIL PROTECTED] wrote:
Mark,
Why don't you post a TODO list for TPC-E somewhere, so people can bite
small pieces off of the list. I'm sure there's lots of people can help
if we do it that way.
This should be a good start:
http://osdldbt.sourceforge.net/dbt5
On Fri, 02 Nov 2007 15:20:27 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
My question is -hackers, is who wants first bite and what do they
want :)
Something I'd like to have back real soon is the daily DBT run against
CVS HEAD that Mark Wong
- So I've
submitted it as a discussion aid, rather than 'the way of fixing
this'... since I'm hoping there is a better way :-)
regards
Mark
Index: src/backend/catalog/namespace.c
===
RCS file: /projects/cvsroot/pgsql/src/backend
we need to re-iterate it few weeks
*before* every feature freeze...)
Cheers
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On 9/25/07, Luke Lonergan [EMAIL PROTECTED] wrote:
Hi Mark,
I haven't yet looked at what you've done, but I'm an enthusiastic supporter
of this idea. We're looking to do something that will view running queries
and allow drill down into those executing at any given time, showing their
plans
On 9/25/07, Euler Taveira de Oliveira [EMAIL PROTECTED] wrote:
Mark Wong wrote:
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show PostgreSQL processes pulled from the
pg_stat_activity table. I have a version that kind of works here
701 - 800 of 1808 matches
Mail list logo
