GUC as suggested. What's your take on the
attached patch?
-sc
--
Sean Chittenden
se...@joyent.com
On Oct 4, 2017, 10:56 AM -0700, Andres Freund , wrote:
> Hi,
>
> On 2017-10-04 10:47:06 -0700, Sean Chittenden wrote:
> > Hello. We identified the same problem. Sam Gwydir
w if there are any questions. -sc
--
Sean Chittenden
se...@joyent.com
w if there are any questions. -sc
--
Sean Chittenden
se...@joyent.com
ism.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
direction before.
>
> If you meant to propose using *unnamed* POSIX semaphores, that might be
> a reasonable change, but it would still need some supporting evidence.
https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-October/003515.html
-sc
--
Sean Chittenden
s...@chittende
54:53.854165855 +0300
> +++ src/template/freebsd2014-05-26 23:55:12.307880900 +0300
> @@ -3,3 +3,4 @@
> case $host_cpu in
>alpha*) CFLAGS="-O";; # alpha has problems with -O2
> esac
> +USE_NAMED_POSIX_SEMAPHORES=1
-sc
--
Sean Chittenden
s...@chittenden
/kib/pgsql_perf.pdf
[2]
http://www.freebsd.org/cgi/man.cgi?query=mmap&apropos=0&sektion=0&manpath=FreeBSD+10.0-stable&arch=default&format=html
[3]
http://www.freebsd.org/cgi/man.cgi?query=madvise&sektion=2&apropos=0&manpath=FreeBSD+10.0-stable
--
Sean Chittende
).
I made a cursory pass over the code and found one other instance where write
status wasn’t being checked and also included that.
-sc
pg_dump_check_write.patch
Description: Binary data
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers
so I thought
I’d prod and ask. Thanks in advance. -sc
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oned above re: breaking out of the loop, there
should probably be a ssl_renegotiation_min tunable so that the client
can't renegotiate too fast.
The default ssl_ciphers in the examples should also be updated as well
(e.g. we still allow SSLv2):
ssl_ciphers =
'ECDHE-RSA-AES128-SHA256:AES128-GC
w releases... and while we're at it, can we prefer PFS ciphers?
> I have still to find where the actual problems are happening in
> unreliable networks ...
I'm guessing you're blocking on /dev/random on some systems and that's
the source of unreliability/timeouts.
> [1] c
at one.
Sounds good to me and is clear enough that it would unblock me w/o having to
resort to the source tree. -sc
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tly what the
problem was. Attached is an improved error message:
> "ERROR: XX000: no schemas in search_path are available for CREATE EXTENSION"
-sc
src-backend-commands-extension.c.patch
Description: Binary data
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers ma
recommending that a cluster not be created at
> a mount point; it should be created in a directory underneath the
> mount point.
Giving filesystem advice is a large topic that I'm sure is covered someplace in
the handbook. A general warning isn't a bad idea, however. *
re of any special directories exposed by
>> filesystems that aren't dot directories so this seems like a relatively
>> futureproof solution, too.
> lost+found
It's been a long time since I've seen that directory. Patch updated. -sc
--
Sean Chittenden
s...@chittenden.org
ll be set to "english".
>
> initdb: directory "/tmp/pginit-test" exists but is not empty
> If you want to create a new database system, either remove or empty
> the directory "/tmp/pginit-test" or run initdb
> with an argument other than "/tmp/pgi
up a test methodology. Using INT8 internally was too
convenient at the time.
--
Sean Chittenden
s...@chittenden.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
em is that this doesn't work in pl/*, which is the problem I
was trying to address. *shrug* -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
r getting just message passing via NOTIFY/LISTEN
to work and will revisit extending things further once I have this bit
done. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
e easier on the
database. Does anyone think there would be any conflicts with the use
of the existing alarm code from storage/lmgr/proc.c for the
LISTEN/NOTIFY interface? It looks like SIGALRM has a reserved purpose.
I haven't found any global alarm handling interface that can be
ot found":
http://people.FreeBSD.org/~seanc/pgmemcache/pgmemcache.pdf
Fixed. Thanks for pointing that out.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-noma
pre-8.0
environment too, fwiw. I don't have any 7.X boxen around though,
they're all on 8.X now. :) I'm very interested in feedback. Anyway,
please let me know if anyone has any questions or problems. I'm
holding off on posting to announce@ for another week or so, may
27;');
RETURN NULL;
END;' LANGUAGE 'plpgsql';
db=# CREATE TRIGGER tbl_inval_trg AFTER INSERT OR UPDATE OR DELETE ON
schma.tbl FOR EACH STATEMENT EXECUTE PROCEDURE schma.tbl_inval();
Very nice. -sc
--
Sean Chittenden
---(end of broadcast)-
ged and
proceed with its handling. This is the preferred approach, IMHO... but
I think is the hardest to achieve (I haven't looked to see what'd be
involved yet).
Enjoy your T-Day commute if you haven't yet. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
tick out like a sore thumb.
Would you be open to increasing this further after the 8.0 release? I
haven't heard of anyone complaining about dropped/fragmented pgstat
messages. :) -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1:
se it more.
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and
NFS over UDP often runs at 32K... where is UDP used in the backend?
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our lis
tement).
Anyway, is there any good reason for this or can this be increased
somehow? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PRO
lient programs
and its libs. I'm sure other packagers may wish to see this happen
too. *shrug* -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
ow what's going on here and will submit a fix for this sometime
tonight. -sc
I think Tom applied a patch already for this.
:) So I noticed. I went to update my sources before sending off a
patch and was greeted with a rather nice conflict. Thanks for getting
to that Tom.
ow what's going on here and will submit a fix for this sometime
tonight. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
still do ALTER USER SET search_path and have that work without
checking.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that yo
n. Can you imagine a
world where chdir(2) didn't validate the existence of directories as
well as the permissions?
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
onf. *shudders* PostgreSQL makes itself "secure" by default
by turning off network access. Once a user is connected, however,
PostgreSQL is an open book and reminds me of the olden days when
/etc/passwd contained crypt(3)'ed passwords and home directories w
27;t necessary
(as Marc says)... you should be able to stop the database and type df
-k && sync && sleep 30 && df -k see space being freed up. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
a way in pg_hba.conf to limit the
number of connections per IP address or per subnet mask? 2 connections
per /32 or 4 connections per /30?
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
nly possible bugs in our own code, but plain old human error
on
the part of the real superuser.
How so? Can you give a scenario where this'd make a difference? I
think putting a trigger on pg_shadow_db to prevent users from mucking
with the UID would be a sufficient anti-foot shooting measure.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
t it is a
hack.
And it doesn't handle the case of letting the local database admin
create users (without giving them access to the rest of the database),
which is what I'm after. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
r if you can set the password for a local user by the
same name.
Agreed, but if a cluster is using LOCAL USERs, I doubt highly that
CLUSTER/GLOBAL users would be in use much beyond super users. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3
CREATE USER/ALTER USER operates on
pg_catalog_db, then CREATE CLUSTER USER/ALTER CLUSTER USER operates on
pg_catalog_cluster.
Nope, other way round, default behavior for backwards compatibility
must
be to create cluster-wide users. CREATE LOCAL USER is what to add.
Ah, good point. -sc
--
Sean Chit
, then CREATE CLUSTER USER/ALTER CLUSTER USER operates on
pg_catalog_cluster.
Tom, what do you think? What other ideas do you have kicking around in
your head?
*shrug* Something for the TODO list and/or an inspired hacker. -sc
--
Sean Chittenden
---(end of broadcast)-
defined as containing features useful for everyone: as
opposed to a re@ release often model where releases don't necessarily
useful features to a majority and just lead to upgrade thrashing which
is costly to organizations. Food for thought... nothing conclusive
here. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
accept that gcc is broken as a whole, I want to hear
> from the GCC folks.
Well, I have no insite into the gcc camp, but, my understanding is
that gcc 3.3 for the alpha isn't broken, but for gcc 2.X, it's pretty
horked with any level of optimization. -sc
--
Sean Chitte
ng and sent it to -patches but got no comments.
http://archives.postgresql.org/pgsql-patches/2003-07/msg00053.php
pg_ping is actually the basis for the threaded benchmark program I've
got sitting in my tree, but I don't think folks here would look kindly
on a -lpthread dependency given how up in the a
compile is small
enough, it's likely that many folks won't notice any appreciable
difference (though it does add up). Here's a thread worth reading
from the gcc guys:
http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00138.html
-sc
--
Sean Chittenden
---(end of br
but
with 32K, it's very possible and much easier to do. Beyond that, I
don't have much else I want to comment on at the moment.
-sc
--
Sean Chittenden
---(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
much success.
>
> > We could call it meta-quoting, or alternative quoting, maybe.
>
> Those seem pretty unmemorable and content-free, though. Any other ideas
> out there?
literal text blocks
literal quotes
literal text sections
-sc
--
Sean Chittenden
-
@ for abs (rarely seen in the wild
from my experience, and has a lower match precedence in flex).
> In any case, @ and % are valid (and popular) operator names in
> Postgres, so we could not use them for this purpose without removing
> that meaning, which would be
BEGIN(SQL);
return(tSTRING);
} else {
/* Do nothing until we hit a match */
}
}
.{
/* Not sure these func names off the top of my head: */
pg_append_str_to_buf(lit_val, yytext, yyleng);
}
%%
/* Or something similarly
r DBAs. If ``'s are needed in the pl language, they can
be nominally included with a \`\`, but given their relative rareness
compared to ' or ", I'd think the addition of ` would be welcome and
much less cumbersome/easier to remember than other options
ng
contexts between procs, but that's a pretty weak argument for only .5M
of shared RAM. For some reason I thought it exec()'ed a child with
the args necessary for it to read in a postgresql.conf. Looks like
the comment in backend/storage/ipc/ipci.c is out of date t
is to change the
LDFLAGS, I was thinking about chasing down where postgres is linked
and splitting apart LDFLAGS into two sets of LDFLAGS: LDFLAGS_CLI and
LDFLAGS (or LDFLAGS_DAEMON, or some such). It's chump, but a few ms
here and there, or a little more IO there eventually add up,
esp
Is it really necessary for postgres to be linked with ncurses (288K)
and readline (156K)? It's .5M, not the end of the world, but it seems
excessive. I know the postmaster has a CLI interface, but does it
really require ncurses or readline? -sc
--
Sean Chittenden
> Does anybody know of a BSD licensed signal implementation that
> compiles on win32?
See how Apache handles this problem (via APR?).
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
ma. I have some read tests I'm going to perform here in a bit,
but I'm waiting for kde to finish compiling before I start testing.
I have another tests machine that I'm going to task with comparing 16K
and 8K blocks. It's not SCSI, but I don't have any available machines
tha
'nother test in support of 16K blocks for FreeBSD, this time it was
25% faster to import. -sc
--
Sean Chittenden
--- Begin Message ---
Hi.
I'm implementing postgresql 7.3.4 on FreeBSD 5.1, and
decided to place the pgsql-folder on it's own
partition so it was easier to test whi
ITA, which is why I asked for comments.
Other than you feeling uneasy about the possibility of uncovering bugs
because this hasn't been widely done like this before, do you have any
other concerns, or do you think the possibility of finding bugs very
likely?
-sc
--
Sean Chittenden
se results to see if it's still 8% faster.. I imagine this'd
make seq scans cheaper on FreeBSD.
Comments? -sc
--
Sean Chittenden
--- Begin Message ---
> > > Like all benchmarks, I doubt these are perfect (or even close)
> > > examples of real-world use.
> >
gt; at configure time, and I don't much want to add it.
The patch gets applied when the port gets built, so there doesn't need
to be a configuration option for it for this to work.
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have y
read tests, I'd be interested
in those results to see if it's still 8% faster. In using 16K blocks,
I'd imagine this'll make using seq scans cheaper on FreeBSD.
Comments? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3
e BSDs dumped support for krb4 from the base, I don't recall a
single email from someone complaining as almost everyone who uses krb
uses hiemdal or MIT krb5. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
only Kerberos 5 is recommended. Kerberos 4 is
> considered insecure and no longer recommended for general
> use.
>
iirc, we were going to depreciate kerberos 4 in the 7.4 release notes
and remove support for it for 7.5, giving users one full release cycle
to move to krb5.
ith larger queries, it's problematic to not be able to use a
cursor in addition to the prepared statement.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Index Scan using report_user_cat_count_html_bytes_idx on report_user_cat_count rucc
(cost=0.00..112165.07 rows=31893 width=64) (actual time=68.64..85.75 rows=514 loops=1)
Index Cond: (html_bytes > 800::bigint)
Total runtime: 97.75 msec
(3 rows)
*shrug* A low ind
hat the use of those comes at great
expense to the CPU (which is inline with a few other papers that I
read). The idea of precomputing values piqued my interest and I
thought was very clever, albeit space intensive. *shrug*
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ter results in my case, it
isn't very adaptive given it uses arbitrary magic numbers.
> >If I manually set the indexCorrelation to 1.0, however, the planner
> >chooses the right plan on its own
>
> Ok, with indexCorrelation == 1.0 we dont have to discuss interpolation
> methods, because they all return min_IO_cost.
>
> >Which suggests to me that line 3964 in
> >./src/backend/utils/adt/selfuncs.c isn't right for multi-column
> >indexes, esp for indexes that are clustered.
>
> Agreed.
>
> > I don't know how to
> >address this though...
>
> I guess there is no chance without index statistics.
>
> >FWIW, this is an old data/schema from a defunct project that I can
> >give people access to if they'd like.
>
> Is there a dump available for download?
Sure, let me post it.
http://people.FreeBSD.org/~seanc/pgsql/rucc.sql.bz2
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ils/adt/selfuncs.c isn't right for multi-column
indexes, esp for indexes that are clustered. I don't know how to
address this though... Tom, any hints?
FWIW, this is an old data/schema from a defunct project that I can
give people access to if they'd like. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
D utc_date = NOW();
SELECT * FROM report_user_cat_count AS rucc WHERE user_id = 42;
SELECT * FROM report_user_cat_count AS rucc WHERE user_id < 1000 AND utc_date >
'2003-01-01'::TIMESTAMP WITH TIME ZONE;
And various timestamps back to 2002-09-19 and user_id's IN(1,42).
-sc
--
Se
l.
Tom, I know you just replaced a bunch of select() calls with poll().
Would you mind if I went through and patched things to use libevent's
abstraction layer?
Once this is done, then I'll go back and use libevent for the
persistent connections goo. -sc
--
Sean Chittenden
---
e parent when a client calls
PQfinish(), not in between transactions.
> Also it sounds to me like the postmaster will now become a
> performance bottleneck, since it will need to be involved in every
> transaction start.
Well, I'm pretty sure you're under the impression I'm chasing a
different goal than the one I'm working toward.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
nsigned int __attribute__((__mode__(__DI__))) __uint64_t;
#else
/* LONGLONG */
typedef long long __int64_t;
/* LONGLONG */
typedef unsigned long long __uint64_t;
#endif
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
es too given the number of security vulnerabilities
associated with the call. :-]
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
, but if
things lag for an instant, the platter will have to make another
rotation before the call comes back to the userland.
Now that I think about it, the optimal case would be to anonymously
mmap() a private buffer that does the read() writes into that way the
HDD could just DMA the data into
on. O_DIRECT eliminates one of these
copies: nevermind the doubling up of data in RAM.
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
he userland API will remain stable (it'll just get more efficient in
6, not that it's not fast as is).
http://lists.freebsd.org/pipermail/cvs-all/2003-March/000261.html
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
id load environment that'd let
any O_DIRECT benchmark be useful isn't trivial.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
O_DIRECT makes writes jump the gun
18:04 <@seanc> got it
18:05 <@seanc> zb^3: is that required in the implementation or is it a bug?
18:06 * seanc is wondering whether or not he should bug dillion about this to
get things working correctly
18:07 <@zb^3> it's a
L buffer
> cache to handle most of the benefits of O_DIRECT, without the
> read-only buffer restriction.
I don't see how this'd be an issue as buffers populated via a read(),
that are updated, and then written out, would occupy a new chunk of
disk to satisfy MVCC. Why wou
o the platter in a
single write by the OS as possible, circumventing that would be
insane (though useful possibly for embedded devices with low RAM,
solid state drives, or some super nice EMC fiber channel storage
device that basically has its own huge disk cache).
2) Last I checked Po
mechanism kicks in and takes effect. Given that the planner
has an idea of how much data it's going to read in in order to
complete the query, seems easier/better to mark the fd O_DIRECT.
*shrug*
-sc
--
Sean Chittenden
---(end of broadcast)-
obvious to me what the change ought to be though.
>
> Please try the attached patch.
>
> I'll try to change kerberos 4 later if I can find some
> documentation about it. Especially the krb_sendauth() function.
>
> Does Kerberos 4 support other protocols than ipv4?
Not
s load or
the disk buffer being emptied and having to be refilled, I'm not sure,
but thinking about it, use of a GUC threshold to have an FD marked as
O_DIRECT does make sense (0 == disabled and the default, but tunable
in Kbytes as an admin sees fit) and could be nice for big queri
ser space, the buffer cache is what helps
speed up PostgreSQL since PostgreSQL leaves all of the caching
operations and optimization/alignment of pages up to the OS (much to
the behest of madvise() which could potentially speed up access of the
VM, but I won't get into that... see TODO.mm
that code's probably 6-8 years old
at this point. If you wanted to be super judicious about preserving
backward compatibility, you could add freebsd2 and freebsd3 to the
list too.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
5.X cases even though their handling is different. -sc
--
Sean Chittenden
pgp0.pgp
Description: PGP signature
tests fail on 5.0 given it should have a tiny user base in
a month.
Making the proposed change above fixes the regression tests on my
5.1... I don't have any 4.X machines I can play with at the moment,
Rod would have to test that.
-sc
--
Sean Chittenden
---(end of br
X has the latest and greatest version of
gdtoa, which fixes many standardization bits in FreeBSD's floating
point routines.
Tom, you said you needed a shell way of detecting this, does the
following work?
if [ "`uname`" = FreeBSD ]; then
if [ "`sysctl -n kern.osreldate`&quo
and checked.
*wanders off to go read -committers*
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
do any recent upgrades and what
version of FreeBSD?
-sc
--
Sean Chittenden
pgp0.pgp
Description: PGP signature
eone said it was OK in a closed environment or
> something. Maybe we need to document that it is not recommended.
Keep krb4 in the tree for 7.4, but before 7.4 gets released, the
documentation and release notes need to state that krb4 has been
depreciated and that it will b
nder-hyped. Historically, PostgresSQL has been consistently
^^ ^^^
ahead of MySQL in enterprise database features with support of
transactions and stored procedures."
heh, understatement of the year++ for an understated project.
-sc
--
Sean Chittenden
---(e
e notoriously slow (slower than NFS) at sending files to
clients. -sc
--
Sean Chittenden
pgp0.pgp
Description: PGP signature
first open source database
> to do something truly useful with XQuery concepts.
Um, why change the backend at all? Why not have libpq do the
interference mapping between the front end and backend so that we can
leave the backend alone? Seems like a simple application of a good
SAX parser t
s no huge press for this, I should have the time do do
this in a few weeks if someone doesn't beat me to it.
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
bit encodings (UCS-2, UCS-4, UTF-16) is on the TODO list, it might
be nice to keep this in mind and let Ruby maintain it instead of
PostgreSQL.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
nges from a log file.
After a threshold, it could be more efficient than having transaction
B re-run its queries.
Like I said, it ain't perfect, but what would be a better solution?
::shrug:: Even OODB's with stats agents have this problem (though
their overhe
e of by DBAs that are intentionally performance
tuning their database, but for those that do, it could be a massive
win. Thoughts? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
we say large page tables? :)
You need an actual 64bit CPU to access more than 4GB of RAM without
paying for it through the nose. -sc
--
Sean Chittenden
msg27765/pgp0.pgp
Description: PGP signature
ug:: In brainstorm mode. Anyway, a few names:
auto_order_join
auto_order_join_max
auto_reorder_table_limit
auto_collapse_join
auto_collapse_num_join
auto_join_threshold
When I'm thinking about what this variable will do for me as a DBA, I
think it will make the plan more intelligent by reordering the
eird platform dependency involved. What's your platform
> >> again?
>
> > I do a make distclean.
>
> > FreeBSD 4.7
>
> I'm still not able to duplicate any problem. Any other FreeBSD folk see
> inet regression failures in
work with. If anyone
runs across any serious problems on FreeBSD, let me know ASAP.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
?
It does, thank you. I've just updated the -devel port to 7.3b4,
hopefully the mirrors will pick up the bits soon. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
1 - 100 of 128 matches
Mail list logo