to be more like pg_locks, and also do the doco. However
I've been a bit hesitant to dive into these last two steps until I see
that there is some real enthusiasm for this patch (or failing that, a
feeling that it is needed...).
i'll let this patch as "needs review" for
encounter should be conservative and usable
out of the box. I can see how "samehost" fits into this picture. I don't
see how "trust" fits into this picture. Does anybody seriously recommend
"trust" to newbies for production use? Shouldn't the default
ch configuration is more likely for the average new user :-)
Anything is better than "trust" - even blocking access entirely!
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
stgreSQL using MD5 is a minor issue -
switching to SHA-1 is not going to eliminate the problem, it will just
make things a tiny bit harder for a would be attacker. To actually close
the window, as opposed to push it closed a little tighter, would take a
lot more effort.
Cheers,
mark
--
effective compared to what we
have today - you need to go all the way. Half way is useless.
Cheers,
mark
--
Mark Mielke
can
safely call the super method that it overrides to provide the underlying
behaviour in the success cases.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n are more ideal for performing this sort
of test.
I rarely ever see this sort of stuff in FOSS projects, and never that I
can remember in FOSS C projects. It's not easy, though.
I assume you are doing it through code changing right now. Commenting
out lines, replacing them with ot
ge our subnet to /25, it's one more thing that
I would have to remember to change unnecessarily.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t things.
How many Postfix servers have you heard of being open relays as a result
of "samenet"? I haven't heard of it ever happening. I suppose it doesn't
mean it hasn't happened - but I think getting the network interface
configured properly being a necessity for the mach
the
start from, and allow the experts to specify IP addresses if that is
what they want to do.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Stephen Frost wrote:
Mark,
Your last email on this patch, from August 9th, indicates that you've
still got "TODO: redo pg_stat_lock_waits ...". Has you updated this
patch since then?
Stephen,
No - that is still a TODO for me - real life getting in the way :-
nents, so this stuff is taken very seriously. The last
thing you want to see on television is a terrorist using an untraceable
"secure" line with your company's brand name on the front, as they lop
off the head of a reporter. There is a level of responsibility required
for such things
On 09/12/2009 04:17 PM, Stephen Frost wrote:
* Mark Mielke (m...@mark.mielke.cc) wrote:
There is no technical requirement for PostgreSQL to separate data in
databases or tables on subdirectory or file boundaries. Nothing wrong
with having one or more large files that contain everything
..
If you can patch PostgreSQL to support such extremes without hurting my
performance - I'll shut up and leave you be. :-)
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/12/2009 03:33 PM, Stephen Frost wrote:
* Mark Mielke (m...@mark.mielke.cc) wrote:
No matter what scheme PostgreSQL uses for storing the data, there can be
underlying file system limitations.
This is true, but there's a reason we only create 1GB files too. I
wouldn't
combining
several tables into one?
Cheers,
mark
On 09/12/2009 02:49 PM, fulan Peng wrote:
Hi, pgsql-committers!
I cannot created more than 32766 databases with freeBSD in one setup,
not as the document says, "as many as you like".
I found the problem is that the directory pgsql/data/b
raphy
(cost=0.00..8.28 rows=1 width=0) (actual time=43.079..172.788 rows=29687
loops=1)
Index Cond: (centroid && $0)
Filter: ((type)::text = 'Z'::text)
Total runtime: 272.185 ms
(8 rows)
So in conclusion, I think that patch looks good and that the extra time
Tom Lane wrote:
There was recently another go-round on the postgis-devel list about
the same problem Mark Cave-Ayland complained about last year:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php
Basically, what is happening is a nestloop join where the inner
indexscan gets a
On 08/12/2009 12:04 PM, Suno Ano wrote:
can anybody tell me, is there a roadmap with regards to
http://www.postgres-r.org ?
I would love to see it become production-ready asap.
Even a breakdown of what is left to do might be useful in case any of us
want to pick at it. :-)
Cheers,
mark
ed replication", "read-only slaves", and "hot standby" are all
100% accurate descriptions of what the hot standby patch enables. I do
like "read only slaves" because it's the most precise and meaningful.
Me too.
Read only slave works for me.
Cheers,
mark
--
Mark Mielke
On 08/11/2009 02:52 PM, Robert Haas wrote:
On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielke wrote:
I remember this debate from 6 months ago. :-)
I prefer not to try and fit square pegs into round holes. Streaming
replication sounds like the best description. It may not be the keywords
that
are looking for, but too bad for them. Calling it something
different than what it is, just so that people who don't understand why
it is wrong will have something that approximates the right
understanding, is not a just cause. :-)
Cheers,
mark
--
Mark Mielke
Mark Kirkwood wrote:
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes
- quite
true. I was thinking it is useful to be able to answer the question
'where
is my wait time
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes -
quite
true. I was thinking it is useful to be able to answer the question
'where
is my wait time being spent' - bu
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes -
quite
true. I was thinking it is useful to be able to answer the question
'where
is my wait time being spent' - bu
Tom Lane wrote:
Mark Kirkwood writes:
Yeah, enabling log_lock_waits is certainly another approach, however you
currently miss out on those that are < deadlock_timeout - and
potentially they could be the source of your problem (i.e millions of
waits all < deadlock_timeout but
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes - quite
true. I was thinking it is useful to be able to answer the question 'where
is my wait time being spent' - but it hides cases like t
rent lines?
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mode?
Cheers,
mark
--
Mark Mielke
I found Tom's response ambiguous - but positive in either way, so it
gave me a smile. :-)
Which of the following two great things occurred?
1) Tom popped a quick fix on CVS HEAD? (Pretty fast!)
2) Tom or somebody else had already done it?
Cheers,
mark
On 07/07/2009 05:14 PM, S
u are just trying to
multiplex multiple queries and responses over the same TCP/IP
connection. For the added complexity on both the client and the server,
do you really think it is worth it?
If you just want a connection multiplexor that is backed by a connection
pool - I think that would be a l
three-line patch. The question of how cursors should behave with
respect to volatile functions can be documented and left for another
time.
Sounds like a good approach.
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Markus Wanner wrote:
Quoting "Mark Mielke" :
I am a theory person - I run things in my head. To me, the concept of
having more context to make the right decision, and an algorithm that
takes advantage of this context to make the right decision, is simple
and compelling on its own. K
27;t work for you, you really are going to have to try
it out for yourself.
Or not.
It doesn't matter to me. :-)
In any case - you raised the question - I explained how it works - and
you shot me done without any evidence of your own. I explained how it
works. It's up to you to try it
er a bit of tuning, not sure how much the out
of the box experience changes on this system.
Now if only I couldn't figure out why oprofile doesn't like this system...
Regards.
Mark Wong
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
enough to completely take them for granted now, and it feels
painful to go back to anything more primitive.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e sane to me, but then somebody else responded that this
was a bad idea, so I pull out of the "is this a good idea or not?"
debate. :-)
Cheers,
mark
--
Mark Mielke
--
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 writes:
As a "for example", you could have a local repo that you publish from.
Your work spaces could be from that local repo.
Yes, exactly. How do I do that? My complaint is that git fails to
provide a distinction between a repo and a workspac
r had a problem.
That said, I wouldn't recommend it be used unless you do in fact
understand the problem well.
Cheers,
mark
--
Mark Mielke
Tom Lane wrote:
Mark Mielke writes:
I'm not following. CVS and SVN both kept such directories "in the
checked out copy." Recall the CSV/*,v files?
I can't speak to SVN, but that is *not* how CVS does it. There's a
small CVS/ directory, but the repository (
Alvaro Herrera wrote:
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git directory bug you now? I'm
genuinely interested as I don't get it. :-)
It doesn't. What bugs me is that
Alvaro Herrera wrote:
Mark Mielke wrote:
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in the
top-level directory, whereas CVS
at you can review history without
network connectivity.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this could be noise. But anything
smaller than 4GB and larger than 8KB looks like a fairly significant
performance drop for DBT2. I wonder if there's any coincidence that
the blocksize of the ext2 filesystem is also 4KB.
Regards,
Mark Wong
--
Sent via pgsql-hackers mailing list (pgs
On Wed, May 27, 2009 at 1:46 AM, Simon Riggs wrote:
>
> On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
>> It appears for this workload using a 16KB or 32KB gets more than 4%
>> throughput improvement, but some of that could be noise.
>
> The baseline appears to have a
dropping yet. It'll be interesting to see if the
combination of changing the table block size can further improve the
performance. It will probably be interesting to try different
filesystems and filesystem blocksizes too.
Regards,
Mark Wong
--
Sent via pgsql-hackers mailing list (pgsql-ha
file is opened.
Regards,
Mark Wong
pgsql-xlog-posix_fadvise-20090425.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
usage of the equipment. Note that the web
page points back to the wiki for information that was already been
created, and that this mailing lists is not intended to replace lists
already in place such as pgsql-hackers or pgsql-performance:
http://perflab.projects.postgresql.org/
Regards,
Mark
quito.
Interesting metaphor... ;)
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
- for
reference the final patch is here
http://postgis.refractions.net/pipermail/postgis-commits/2008-January/000199.html.
I appreciate it may not be 100% relevant, but I thought I'd flag it up
as possibly being a fault with the MingW putenv implementation.
HTH,
Mark.
--
Mark Cav
that does DDL transparently and is up to date within a
controllable time frame. Bluntly, it looks like a killer feature.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of those and keeping the detail is
unlikely to be useful. It would be easy to collect them all together in
one transaction entry.
regards
Mark
lockstats-1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Simon Riggs wrote:
On Sat, 2009-01-24 at 11:20 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reapp
Simon Riggs wrote:
On Thu, 2009-01-22 at 22:35 +, Simon Riggs wrote:
* Bug fix v9 over next few days
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
master:
=# create database test
ng it in this release and spending further time on it. I'm happy
to stand by this going forwards.
+1
+1
I've been testing several versions of this patch, and overall it looks
very good.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Gregory Stark wrote:
Mark Mielke writes:
It seems to me that transparent file system compression doesn't have limits
like "files must be less than 1 Mbyte to be compressed". They don't exhibit
poor file system performance.
Well I imagine those implementations a
et
of blocks basis allowing for seek into the block, or if compression
doesn't seem to be working for the first few blocks, the later blocks
can be stored uncompressed? Or is that too complicated compared to what
we have now? :-)
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-ha
Simon Riggs wrote:
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# \d history
Table "public.history"
Column |Type | Modifiers
+-+---
tid| integer |
bid
Mark Kirkwood wrote:
Simon Riggs wrote:
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# \d history
Table "public.history"
Column |Type | Modifiers
+-+---
tid
id| integer |
aid| integer |
delta | integer |
mtime | timestamp without time zone |
filler | character(22) |
bench=# select now(),count(*) from history;
ERROR: could not open relation base/16384/16394: No such file or directory
that don't know better to guilt them into thinking twice before
doing whatever they are doing, than an actual legal requirement for
enforcement of copyright restrictions.
Cheers,
mark
--
Mark Mielke
explicit. The implicit copyright may be "All rights reserved" whereas
the explicit copyright may say "You may use this software for free
provided that you do not hold the authors responsible for any damages
caused by use of the software". Which is more restrictive?
Cheers,
s a
guarantee that all of the stand bys will fall "more behind" for a period
(a few seconds to a minute?), but they will catch up shortly after the
peak is over.
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ution though which is in
line with what you are saying? :-)
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
les near linear to the number of nodes in the system, even at the
expense of immediately visible transactions from all servers, I can
accept that sometimes the expectations are stricter and would appreciate
seeing an option to let me choose based upon my requirements.
Cheers,
mark
Markus Wa
On Mon, Dec 8, 2008 at 4:34 PM, Tom Lane wrote:
> "Mark Wong" writes:
>> On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane wrote:
>>> Are any of the queries complicated enough to trigger GEQO planning?
>
>> Is there a debug option that we could use to see?
>
>
e know people have the expectation. We know it
can be convenient. Is the expectation valid in the first place?
I've probably drawn this question out too long and should do my own
research and report back... Sorry... :-)
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing li
Heikki Linnakangas wrote:
Mark Mielke wrote:
FYI: I haven't been able to prove this. Multiple sessions running on
my dual-core CPU seem to be able to see the latest commits before
they begin executing. Am I wrong about this? Does PostgreSQL provide
a intentional guarantee that a commit
Mark Mielke wrote:
Forget replication - even for the exact same server - I don't expect
that if I commit from one session, I will be able to see the change
immediately from my other session or a new session that I just opened.
Perhaps this is often stable to rely on this, and it is usefu
ns see the latest
snapshot, so would this not imply that all sessions would be redirect to
the 'primary'? I don't think it is reasonable myself, but I might be
misunderstanding something...
Cheers,
mark
--
Mark Mielke
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
me), I think it's clear that two phase commit guarantees that the
commit has taken place, but does *not* guarantee anything about visibility.
It might be a good bet - but guarantee? There is no such guarantee.
Cheers,
mark
--
Mark Mielke
transaction is
available is by during communication between the processes or threads,
or between the multiple CPUs on the machine. Do I want every commit to
force each session to become fully in alignment before my commit
completes? Does PostgreSQL make this guarantee today? I bet it doesn't
if you look far enough into the guts. It might be very fast - I don't
think it is infinitely fast.
Cheers,
mark
--
Mark Mielke
't understand the problem. Even if PostgreSQL
didn't use the word "synchronous replication", I could still be
confused. I need to understand the problem no matter what words are used.
Cheers,
mark
--
Mark Mielke
icated enough to trigger GEQO planning?
Is there a debug option that we could use to see?
Regards,
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
some bizarre interaction
between CLUSTER/VACUUM/autovacuum?
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:
YZE
count
---
0
(1 row)
CLUSTER
ANALYZE
count
---
0
(1 row)
So in other words, the contents of the temporary table has just
disappeared :(
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
-- Count s
On Mon, Dec 1, 2008 at 9:32 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Dec 2008, Mark Wong wrote:
>
>> So then I attempted to see if there might have been difference between the
>> executing time of each individual query with the above parameters. The
>>
someone actually wanted to put some effort into this, I'd suggest
> taking some reasonably complex benchmark (maybe TPCH or one of the DBT
> series) and plotting planner runtime for each query as a function of
> statistics_target, taking care to mark the breakpoints where it shifted
someone actually wanted to put some effort into this, I'd suggest
> taking some reasonably complex benchmark (maybe TPCH or one of the DBT
> series) and plotting planner runtime for each query as a function of
> statistics_target, taking care to mark the breakpoints where it shifte
Simon Riggs wrote:
On Tue, 2008-11-04 at 18:33 +1300, Mark Kirkwood wrote:
postgres=# \l
List of databases
Name| Owner | Encoding | Collation | Ctype | Access
Privileges
Simon Riggs wrote:
On Mon, 2008-11-03 at 12:16 +1300, Mark Kirkwood wrote:
Trying out a few different scenarios I ran across this:
1/ Setup master and replica with replica using pg_standby
2/ Create a new database ("bench" in my case)
3/ Initialize pgbench schema size 100
4/
ebsd boxes, as there
may be something rotten with the src tree I'm using there...
Scratch that - I was just being too impatient - after a few more minutes
the replica on Freebsd was accessible ok. So this one is entirely user
error!
regards
Mark
--
Sent via pgsql-hackers mailing list
Simon Riggs wrote:
On Tue, 2008-11-04 at 18:33 +1300, Mark Kirkwood wrote:
While doing some tests yesterday I ran into the situation where the
standby database would appear to go back into 'warm' mode after it was
restarted. The set of steps to reproduce the behaviour is:
1/ Se
StartupXLOG () at xlog.c:5959
#2 0x080f1680 in AuxiliaryProcessMain (argc=2, argv=0xbfbfe6e8)
at bootstrap.c:421
#3 0x08214d4d in StartChildProcess (type=StartupProcess) at
postmaster.c:4104
#4 0x0821725b in PostmasterMain (argc=1, argv=0xbfbfec50) at
postmaster.c:1034
#5 0x081bfa7b in mai
esses
DEBUG: server process (PID 2981) exited with exit code 1
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing dead processes
LOG: startup process (PID 12600) was terminated by signal 6: Abort trap
LOG: aborting startup due to startup process failure
DEBUG: proc_exit(1)
DEBUG: shmem_exit(1)
DEBUG: exit(1)
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
for the on disk size savings, these are worth
having for data warehousing situations.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
there still scope for getting something like this in 8.4 - or this patch
still far shy of anything ready for a commit fest? I have a feeling that
working on this is something currently beyond my own capability :(
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
al formats is the direction
of supporting every UUID format. Three months from now, somebody is
going to propose allowing '-' or ':'. What should the answer be then?
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
ntation was used for the PostgreSQL core, but
any hard coded constants would allow for the optimizer to generate
instructions that can run in parallel, or that are better aligned to
machine words.
2-3% slow down for what gain? It still doesn't handle all cases, and
it's less able to
lty cell in it, it will
create a fault a percentage of every time it is accessed. One bit error
easily turns into two, three, ... Then there is the fact that no
hardware is perfect, and every single component in the computer has a
chance, however small, of introducing bit errors... :-(
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
at avoiding double-buffering by using
writev() would be preferred.
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
ility, we wouldn't need fixed
columns at all?
But yes - I tend to agree that the object persistent layer can be hidden
away behind something like the Java object persistence model,
automatically doing alter table or providing a configured mapping from a
description file. This isn't a problem that needs to be solved at the
database layer.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
reSQL
can be extended with pluggable languages, for which I think the answer
is already a yes. If some parts of PostgreSQL are not performance
bottlenecks, and they are extremely complicated to write in C, and very
easy to write in something else common and simple (I've never used LUA
are not ordered? Perhaps the only
thing that is wrong is that a suitable ERROR message is missing?
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
-- Initial data
--
CREATE TABLE ctest (
id int8,
nam
to know what the
advantages would be to "upgrade" the code to C99 standards
The code might look a little bit cleaner, but other than that, I don't
see it running faster or being significantly smaller.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
the result will be a bust.
I'd rather core developer effort was spent doing what they are doing today.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
PostgreSQL is currently ported and 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/mailpref/pgsql-hackers
ant of the code is around in the Bizgres repository
(src/backend/utils/resscheduler I think) - some bits might be worth
looking at!
Best wishes
Mark
P.s : I'm not working for Greenplum now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
oment, but Bob would be happy to answer questions.
Regards,
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
601 - 700 of 1847 matches
Mail list logo
