On 10/31/2011 06:54 AM, Marcin Mańk wrote:
On Sun, Oct 30, 2011 at 8:50 PM, Eric Ridgeeeb...@gmail.com wrote:
Well, it's a display thing as much as any SELECT statement
(especially via psql) is a display thing. It's more like I want
all 127 columns, except the giant ::xml column, and I'm too
Stupid question:
Is this just a display thing? Or does this have impact for things such
as COUNT(*) vs COUNT(1)?
Is it like a view, but on the fly?
I'm found myself in the *occasional* (certainly not daily!) situation
where such a feature might be useful, but each time I wonder about if
On 10/30/2011 03:50 PM, Eric Ridge wrote:
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielkem...@mark.mielke.cc wrote:
2) Not deterministic (i.e. a database change might cause my code to break),
Okay, I'm inventing a use-case here, but say you have a users table
with various bits of metadata about
On 10/07/2011 11:02 PM, Greg Stark wrote:
All that said I think this is far murkier than you all seem to think.
Copyright law is one of the most complex areas of the law and this is
one of the least well defined parts of copyright law.
Hi Greg:
I don't think we all think this issue is
My original read of the problem determined (for me personally) that the
only way one could be in violation of copyright was if the data was
incorrect (i.e. not factual). It presented an interesting contradiction.
The only way they could sue is by agreeing that their data is faulty and
should
On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
If we allow the invention of new explain states we'll never be able to
publish an authoritative schema definition of the data. That's not
necessarily an argument
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
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/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
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/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/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 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 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
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 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
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/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/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 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 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/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.
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 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
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 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
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 07/08/2009 09:59 AM, Kevin Grittner wrote:
Dimitri Fontainedfonta...@hi-media.com wrote:
4. sync: slave is no more lagging, it's applying the stream as it
gets it, either as part of the master transaction or not
depending on the GUC settings
I think the interesting
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, Sergey
On 06/18/2009 02:42 AM, Pavel Golub wrote:
Now to implement customer's desire in PostgreSQL there are two ways:
1. Each script must be executed in the separate connection context
2. Each script must be executed inside critical section, in other
words current scipt must block others until
Markus Wanner wrote:
Quoting Mark Mielke m...@mark.mielke.cc:
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
for granted now, and it feels
painful to go back to anything more primitive.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
! excellent!
--
Mark Mielke m...@mielke.cc
--
Mark Mielke m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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 the database (the pulled
Tom Lane wrote:
Mark Mielke m...@mark.mielke.cc 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 (with all
wouldn't recommend it be used unless you do in fact
understand the problem well.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
Tom Lane wrote:
Mark Mielke m...@mark.mielke.cc 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
of the is this a good idea or not?
debate. :-)
Cheers,
mark
--
Mark Mielke m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql
Gregory Stark wrote:
Mark Mielke m...@mark.mielke.cc 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
. 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,
mark
--
Mark Mielke m...@mielke.cc
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 m...@mielke.cc
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 m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
,
mark
--
Mark Mielke m...@mielke.cc
--
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:
Where does the expectation come from?
I find the seat reservation, bank account or stock trading examples
pretty obvious WRT user expectations.
Nonetheless, I've compiled some hints from the documentation and sources:
Since in Read Committed mode each new command
about visibility.
It might be a good bet - but guarantee? There is no such guarantee.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
be
misunderstanding something...
Cheers,
mark
--
Mark Mielke m...@mielke.cc
--
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:
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 useful
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 from
. 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 m...@mielke.cc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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 m...@mielke.cc
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 m...@mielke.cc
should the answer be then?
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
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]
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]
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
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]
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
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]
, 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
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
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
1 - 100 of 176 matches
Mail list logo
