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
will be a bust.
I'd rather core developer effort was spent doing what they are doing today.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
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]
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
myself?), I imagine it would be acceptable to the community.
Cheers,
mark
--
Mark
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]
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
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]
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 check the format for correctness.
Cheers,
mark
--
Mark Mielke
should the answer be then?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
My two cents - if it's desired -
I invariably disable selinux from all of my production machines. Once
upon a time I tried to work with it time and time again - but it was
such a head ache to administer for what I considered to be marginal
gains, that I eventually gave up. Every time I add a
On 01/22/2010 09:52 AM, Greg Sabino Mullane wrote:
Well, this *was* posted to -hackers and not -advocacy, but
advocacy, mind share, and many other non-hacking-on-the-base-code things
matter too. And frankly, our name is one of our *top* problems.
Perhaps you've never had to explain to
On 01/22/2010 10:57 AM, Aidan Van Dyk wrote:
* Brendan Jurddire...@gmail.com [100122 10:29]:
Holy query language, Batman!
Do you mean to tell me that the uninformed masses you interact with
have an understanding of what SQL means?
I am skeptical of this claim, but if true, you must have
On 01/29/2010 09:01 PM, Tom Lane wrote:
Maybe. We concluded in the April 2009 thread that
standard_conforming_strings = ON had gotten little or no field testing,
and I don't see any strong reason to hope that it's gotten much more
since then. It would be rather surprising if there *aren't* any
On 02/03/2010 01:20 PM, Robert Haas wrote:
I am not sure I really understand why anyone is a rush to make this
change. What harm is being done by the status quo? What benefit do
we get out of changing the default? The major argument that has been
offered so far is that if we don't change it
On 02/03/2010 02:15 PM, Robert Haas wrote:
The longer we wait before making an
incompatible change, the more people will have adjusted their code to
the new reality (or upgraded their drivers, etc.) and the fewer things
will break.
In my experience, the opposite is true, although in this
On 02/09/2010 08:46 AM, Jeroen Vermeulen wrote:
This sounds like a really nice to have feature. Maybe it'd also be
possible to skip replanning between executes if the current bound
values are 'indexwise-equivalent' to the values used at previous
planning, i.e. nothing in the statistics
On 02/11/2010 08:13 AM, Bart Samwel wrote:
ISSUE #1: Performance / caching
At present, I've simply not added caching. The reasoning for this is
as follows:
(a) getaddrinfo doesn't tell us about expiry, so when do you refresh?
(b) If you put the cache in the postmaster, it will not work for
On 02/11/2010 04:54 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 16:36, Mark Mielke m...@mark.mielke.cc
mailto:m...@mark.mielke.cc wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination. I
would suggest allowing lists of hostnames
On 02/11/2010 05:12 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 23:01, Mark Mielke m...@mark.mielke.cc
mailto:m...@mark.mielke.cc wrote:
On 02/11/2010 04:54 PM, Bart Samwel wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask
On 02/11/2010 09:38 PM, Euler Taveira de Oliveira wrote:
Mark Mielke escreveu:
Of course, then I'll ask for the ability to simplify specifying multiple
databases:
We already support multiple users and/or databases for a single pg_hba.conf
line ...
Is there a reason you trimmed
On 02/14/2010 03:24 PM, Florian Weimer wrote:
* Tom Lane:
Which options would that be? I am not aware that there any for any of the
recent linux filesystems.
Shouldn't journaling of metadata be sufficient?
You also need to enforce ordering between the directory update and
On 02/14/2010 03:49 PM, Andres Freund wrote:
On Sunday 14 February 2010 21:41:02 Mark Mielke wrote:
The widely reported problems, though, did not tend to be a problem with
directory changes written too late - but directory changes being written
too early. That is, the directory change
My preference is to deal with the specific value vs generic value issue.
For this issue, it can affect performance even if PREPARE/EXECUTE is
execute exactly once.
In the last case I saw, a certain query was executing once every second,
and with a specific value it would take 1 ms, and with
On 02/26/2010 05:20 AM, Jeroen Vermeulen wrote:
Mark Mielke wrote:
All the points about ms seem invalid to me. There are many reason why
ms could increase, and many of them have nothing to do with plan
efficiency. Again, re-planning due to a high ms, or a high ratio of
ms, does not indicate
On 02/26/2010 11:27 AM, Tom Lane wrote:
Also, I think there is a lot of confusion here over two different
issues: generic plan versus parameter-specific plan, and bad planner
estimates leading to a wrong plan choice. While the latter is certainly
an issue sometimes, there is no reason to
On 02/26/2010 01:59 PM, Tom Lane wrote:
... It's walking around the problem
that the idea of a generic plan is just wrong. The only time a generic
plan is right, is when the specific plan would result in the same.
I think that's a significant overstatement. There are a large number
of
On 02/26/2010 01:59 PM, Tom Lane wrote:
Mark Mielkem...@mark.mielke.cc writes:
Just to point out that I agree, and as per my original post, I think the
only time prepared statements should be re-planned for the statistics
case, is after 'analyze' has run. That sounds like a quicker
On 02/26/2010 02:57 PM, Tom Lane wrote:
Mark Mielkem...@mark.mielke.cc writes:
There must be some way to lift the cost of planning out of the plan
enumeration and selection phase, such that only plan enumeration and
selection is run at execute time. In most cases, plan enumeration and
On 02/26/2010 03:11 PM, Yeb Havinga wrote:
Tom Lane wrote:
Right, but if the parameter is unknown then its distribution is also
unknown. In any case that's just nitpicking, because the solution is
to create a custom plan for the specific value supplied. Or are you
suggesting that we should
On 02/26/2010 07:03 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Basically, what I really want here is some kind of keyword or other
syntax that I can stick into a PL/pgsql query that requests a replan
on every execution.
Wouldn't it be better if it just did the
On 02/27/2010 11:20 PM, Craig Ringer wrote:
Essentially, you have:
1) People preparing statements to save on parse+plan time; and
2) People preparing statements to get convenenient param placement.
I suspect that most of (1) also want (2), but many of (2) don't care
much about (1) and are
and after a HOT update compared to before and after a regular update.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
/update. Based on the above, it appears that every time an HOT
update occurs, 4 to 8 bytes might get wasted in the page. Eventually
this fills the page and a regular cold update is required and it is cleared.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end
that the account is not a user account.
On my system
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
$ grep postgres /etc/shadow
postgres:!!:13665:0:9:7:::
It is not possible to login as postgres directly.
Cheers,
mark
--
Mark Mielke [EMAIL
a potential for discovering the filenames
present in . and .. --- how much do we care about that?
No more than discovering the file names in any other directory without
using '.' or '..'? If it matters, check to ensure it is a regular file
before opening it?
Cheers,
mark
--
Mark Mielke [EMAIL
clear whether anyone but me thought that was a good
argument. I'm willing to make it just be no-dir-separators.
I think it is a good argument.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: In versions below 8.0
should be spent on this subset.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
Michael Glaesemann wrote:
On Sep 6, 2007, at 10:53 , Mark Mielke wrote:
I don't like the truncating hash suggestion because it limits the
ability of a hash code to uniquely identify a key.
AIUI, a hash can't be used as a unique identifier: it always needs to
be rechecked due to the chance
the performance of re-checking was near free when compared to the cost
of looking up the tuples in the table to determine whether or not they
are live. This is why I have not been upset that bitmap index scans
often re-check.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
), then the index record 3
points to tuple 3, and it exists. Only, it doesn't because 'a' 'z'.
You MUST check the value.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
. The loss, however, is that the hash index data structures become
more complex, and would likely require support for variable length data.
The resulting increase in hash index size and code complexity would
reduce performance.
Just an opinion.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
the key, nor the header data
required (length prefix?).
Please keep the ideas and comments coming. I am certain that a synthesis
of them will provide an implementation with the performance characteristics
that we are seeking.
The subject interests me. :-)
Cheers,
mark
--
Mark Mielke [EMAIL
, as btree often
requires 1 index page scan.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
remain on
the heap.
Wouldn't the extreme be - even the visibility information is in the
index? :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 08/11/2009 09:56 AM, Kevin Grittner wrote:
Bruce Momjianbr...@momjian.us wrote:
OK, so it is warm slave.
That is technically accurate, given the preceding definitions, but it
has disturbing connotations. Enough so, in my view, to merit getting
a little more creative in the
On 08/11/2009 02:52 PM, Robert Haas wrote:
On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielkem...@mark.mielke.cc 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
On 08/11/2009 11:19 PM, Robert Haas wrote:
On Tue, Aug 11, 2009 at 9:44 PM, Greg Starkgsst...@mit.edu wrote:
No! This is *not* what hot standby means, at least not in the Oracle world.
I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby
Admittedly,
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
Not sure that this really belongs on pgsql-committers - maybe pgsql-hackers?
No matter what scheme PostgreSQL uses for storing the data, there can be
underlying file system limitations. One solution, for example, would be
to use a file system that does not have a limitation of 32k
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 be against
On 09/12/2009 03:48 PM, Stephen Frost wrote:
This would allow for 220M+ databases. I'm not sure how bad it'd be to
introduce another field to pg_database which provides the directory (as
it'd now be distinct from the oid..) or if that might require alot of
changes. Not sure how easy it'd be to
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
On the subject of crypto law - the laws have relaxed significantly in
the last decade to the point where it is now generally safe to export
symmetric encryption up to 128 bits (example: AES), and assymetric
encryption up to 1024 bits (example: RSA). Many countries still require
some sort of
If looking for representation -
I consider the default pg_hba.conf to be problematic. Newbies start with
trust access, and then do silly things to open it up.
I would use samehost, and if samenet worked the same way it does for
Postfix, I would probably use samenet. This information can be
On 09/23/2009 05:37 PM, Andrew Dunstan wrote:
Tom Lane wrote:
In this case what particularly scares me is the idea that 'samenet'
might be interpreted to let in a larger subnet than the user expected,
eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
after you'd been
On 09/23/2009 05:40 PM, Tom Lane wrote:
I haven't looked at this feature at all, but I'd be inclined, on the
grounds you quite reasonably cite, to require a netmask with samenet,
rather than just ask the interface for its netmask.
I was just thinking the same thing. Could we then unify
On 09/26/2009 10:04 AM, Simon Riggs wrote:
If you think there's
something useful I could do, let me know and I'll take a look.
I feel like I need a better way of unit testing new code. Some of the
code in the patch is to handle corner cases, so recreating them is
fairly hard. It is a
On 09/26/2009 02:28 PM, Dan Colish wrote:
There are a variety of projects dedicated to creating C unit test
frameworks. I don't have a lot of experience with them, but I have heard
good things about check and cunit. Here's a link I found with a longer
list of frameworks.
On 09/29/2009 09:07 AM, Gurjeet Singh wrote:
On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com writes:
Hmmm, that would be a useful, easy (I think) security feature:
add a GUC
On 09/29/2009 12:54 PM, Josh Berkus wrote:
I read Josh's original suggestion to eventually evolve to if a
particular user account from a particular IP address uses the wrong
password more than N times in T minutes, than the IP address is locked
out for U minutes. This is the *only* way of
On 09/30/2009 10:08 PM, Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
On 10/01/2009 10:24 AM, Kevin Grittner wrote:
Trust authentication has a few valid use cases, but it does tend to
worry me that people may leave it enabled in inappropriate situations
on production clusters. I don't see how we could get rid of it, but
I'd be OK with a warning in the log when a
On 10/14/2009 12:25 PM, Tom Lane wrote:
Let's see you do that (hint: CREATD USER ... PASSWORD is going to
throw a syntax error before you realize there's anything there that
might need to be protected).
And you ignored the question of insecure transmission pathways, anyway.
By the time the
On 10/14/2009 05:33 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Can they check the box if the provided clients include password
strength checking? I'm just wondering if we're going at this the hard
way, if that really is the main
On 10/14/2009 06:02 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Well, sure, but we're talking about a client going out of their way to
wrestle the point of the gun toward their own foot, aren't we? If
we're worried about the
On 10/14/2009 06:25 PM, Peter Eisentraut wrote:
On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote:
So throwing out a wild idea that's probably just wild enough to even
consider, but one way to deal with the logging side of things would be
to deprecate/remove ALTER USER/CREATE USER
On 10/15/2009 03:54 AM, Dave Page wrote:
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielkem...@mark.mielke.cc wrote:
On 10/14/2009 05:33 PM, Dave Page wrote:
No. Any checks at the client are worthless, as they can be bypassed by
10 minutes worth of simple coding in any of a dozen or
On 10/15/2009 10:08 AM, Dave Page wrote:
It's certainly true that there are other ways for users to compromise
their passwords if they want. The fact remains though, that most other
DBMSs (and all major operating systems I can think of) offer password
policy features as non-client checks which
On 10/15/2009 10:38 AM, Albe Laurenz wrote:
Mark Mielke wrote:
Does Oracle really do password checks on the base SQL commands used to
change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created
On 10/15/2009 01:44 PM, Dave Page wrote:
I don't deal with prospective clients, which is where this comes from.
I do deal with a team of (pre)sales engineers who complain about this,
and maybe half-a-dozen other issues on a very regular basis. They tell
me that PostgreSQL loses out in early
On 10/15/2009 02:02 PM, Dave Page wrote:
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haasrobertmh...@gmail.com wrote:
OK, so we're in violent agreement here?
From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that
On 10/16/2009 11:28 AM, Bruce Momjian wrote:
Dave Page wrote:
Too many of those caveats, and it's easy to see how we can be
discounted early in the evaluation phase. It's not helped that often
these lists will be drawn up by people used to working with the
commercial DBMSs, so we probably
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
, 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
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
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
recursion. :-)
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]
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]
, if it were to say an alternative form of ELSEIF is to nest IF
statement like so: ...
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
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
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
be that the optimizer will generate similar best code for each.
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 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
, and then
demanded as a standard to be applied to all other products.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
.
---
--
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
Gregory Stark wrote:
Mark Mielke [EMAIL PROTECTED] writes:
I'm sure one or two examples must exist, but I cannot think of any. Every
enhancement I can think of that eventually made it into a standard, was first
implemented within a popular product, and then demanded as a standard
nothing, right?
Why does MySQL have a 3-byte integer support if they truly believe that
saving 1 byte in 4 doesn't result in a savings for keys?
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
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]
. 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
.
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]
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
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]
1 - 100 of 176 matches
Mail list logo
