On Thu, Jan 19, 2006 at 02:46:11AM -0500, Tom Lane wrote:
The concerns that I find more interesting are changes in the underlying
objects. We don't have an ALTER OPERATOR CLASS, much less an ALTER
ACCESS METHOD, but it's certainly theoretically possible to change the
definition of a support
Fellow hackers,
I'm curious about the best way to handle something like this:
GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
Is it reasonable to restrict this to a single relation, and throw an error
if multiple relations are specified? That would require the preceding
grant
On Thu, Jan 19, 2006 at 12:06:41AM -0500, Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
As far as I can tell, the only difference between your position,
Dann, and Date and Darwen's, is that you think no natural key is
immutable.
DD's examples of natural keys are worth a
On Thu, Jan 19, 2006 at 12:50:52AM -0800, David Fetter wrote:
On Thu, Jan 19, 2006 at 12:06:41AM -0500, Tom Lane wrote:
No, that's not the big problem. The big problem is that it's very
likely illegal for you to use it for anything unless you happen to be
the Social Security Administration.
Since 8.0, postmaster.opts has been containing .../bin/postgres even though
the postmaster was started. This was evidently broken by some
Windows-related reshuffling.
Earlier, CreateOptsFile was called with argv, now it's passed the result of
find_my_exec instead. I'm not sure whether that
Bruce Momjian wrote:
OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.
However, the big difference seems to be
On Wed, Jan 18, 2006 at 05:27:29PM -0500, Tom Lane wrote:
Right, the deadlock risk is exactly the reason you need some secret
sauce or other. Btree's page-level lock ensures that two insertions of
conflicting keys can't overlap (even if they ultimately get stored on
different pages). That's
As an Oracle internals person myself, I don't see how making a comparison between the specifics of Oracle's MVCC to PostgreSQL's MVCC is relevant to this discussion.As does *MOST* other commercial databases, Oracle's storage manager performs an update-in-place whereas PostgreSQL's (for the most
Am Donnerstag, 19. Januar 2006 09:50 schrieb kevin brintnall:
GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
Is it reasonable to restrict this to a single relation, and throw an error
if multiple relations are specified?
Yes
--
Peter Eisentraut
Martijn van Oosterhout wrote:
Please provides natural keys for any of the following:
- A Person
- A phone call: (from,to,date,time,duration) is not enough
- A physical address
- A phone line: (phone numbers arn't unique over time)
- An internet account: (usernames not unique over time
On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
Martijn van Oosterhout wrote:
Please provides natural keys for any of the following:
- A Person
- A phone call: (from,to,date,time,duration) is not enough
- A physical address
- A phone line: (phone numbers arn't unique over
kevin brintnall [EMAIL PROTECTED] writes:
GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
Is it reasonable to restrict this to a single relation, and throw an error
if multiple relations are specified?
The SQL spec doesn't actually allow multiple things after GRANT ... ON
On Thu, Jan 19, 2006 at 01:56:51AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Oracle does, but you pay in other ways. Instead of keeping dead tuples
in the main heap, they shuffle them off to an 'undo log'. This has some
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Odd problem with unique indexes:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
OK, scratch that
lc_collate | C
lc_ctype | C
OK, scratch that theory. Don't suppose you can create a reproducible
test case ;-)
That may be a bit tough... What really struck me is that the
duplication only occurs in this set of 100 tables and the
duplication is
[EMAIL PROTECTED] writes:
On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
Martijn van Oosterhout wrote:
Please provides natural keys for any of the following:
- A Person
- A phone call: (from,to,date,time,duration) is not enough
- A physical address
- A phone line:
Joshua D. Drake wrote:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
You don't user pl/perl, do you -- i.e.
Jonah H. Harris [EMAIL PROTECTED] writes:
As an Oracle internals person myself, I don't see how making a comparison
between the specifics of Oracle's MVCC to PostgreSQL's MVCC is relevant to
this discussion.
As does *MOST* other commercial databases, Oracle's storage manager performs
an
Peter Eisentraut [EMAIL PROTECTED] writes:
Earlier, CreateOptsFile was called with argv, now it's passed the result of
find_my_exec instead. I'm not sure whether that change was wrong to begin
with or whether find_my_exec is mishaving (it should return something
containing postmaster,
On 19 Jan 2006 11:25:21 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Well it seems there were lots of facts posted. Yes you can avoid headachescaused by these issues, but we're not really talking about the headaches.Several were mentioned; some of which could generally be avoided by good tuning.
On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
The point? Surrogate keys and natural keys are two tools in the
database arsenal. Just as it is unwise to use a hammer to drive a screw
just because you don't believe in screwdrivers, it is unwise to just off
hand discard either
Tom Lane wrote:
find_my_exec is not misbehaving: it's designed to expand symlinks,
and would in fact be pretty useless if it did not.
I don't want to contest that in certain cases this is required but I can
easily come up with scenarios (which perhaps no PostgreSQL user has
encountered yet)
Martjin,
In any of these either misspellings, changes of names, ownership or
even structure over time render the obvious useless as keys. There are
techniques for detecting and reducing duplication but the point is that
for any of these duplicates *can* be valid data.
Please point me out
Jim,
So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate when you have a good reason to do so.
The lazy man's guide to SQL database design, but Jim Nasby.
;-)
--Josh
---(end of broadcast)---
TIP 3: Have you
Jonah,
David has stated that the index to heap visibility check is slowing him
down, so what are the possible options:
- Visibility in indexes (-hackers archives cover the pros/cons)
- True organized heaps
- Block level index (Tom/Simon's earlier discussion)
also
- Frozen relations
This
Michael Paesold wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
You don't user
Thanks for all the help and thought to our problem.
Jonah H. Harris wrote:
David has stated that the index to heap visibility check is slowing
him down, so what are the possible options:
- Visibility in indexes (-hackers archives cover the pros/cons)
- True organized heaps
- Block level
Tom Lane wrote:
What sort of problems are you dealing with exactly? There has been
some discussion of changes that would improve certain scenarios. For
instance it might be plausible to do joins using index information and
only go back to the heap for entries that appear to pass the join
On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate when you have a good reason to do so.
The lazy man's guide to SQL database design, but Jim Nasby.
;-)
Hehe... I was thinking the same thing. I've
Hi there,
we did a 8.1 compatible version of tsearchd, available from
http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch2
tsearchd is our old experiment with inverted index. It's
fully compatible with tsearch2, actually it's tsearch2+several functions
and daemon. Very brief documentation
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: Thursday, January 19, 2006 10:09 AM
To: Martijn van Oosterhout
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Surrogate keys (Was: enums)
Martjin,
In
On Thu, Jan 19, 2006 at 02:25:15PM -0500, uwcssa wrote:
i have a table that is already vacuumed. for some reason i want
to un-vacuum it instead of dropping the table and recreate the table
and indexes on it. is there a existing command to do so?
What effect do you want this un-vacuum to
On 1/19/06, uwcssa [EMAIL PROTECTED] wrote:
I have a simple question here, not sure if i should posted here but
if you have the quick answer, it helps a lot
i have a table that is already vacuumed. for some reason i want
to un-vacuum it instead of dropping the table and recreate the table
Ühel kenal päeval, N, 2006-01-19 kell 14:25, kirjutas uwcssa:
I have a simple question here, not sure if i should posted here but
if you have the quick answer, it helps a lot
i have a table that is already vacuumed. for some reason i want
to un-vacuum it instead of dropping the table and
On Thu, Jan 19, 2006 at 02:01:14PM -0500, [EMAIL PROTECTED] wrote:
On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate when you have a good reason to do so.
The lazy man's guide to SQL database
On Thu, Jan 19, 2006 at 11:22:24AM -0800, Dann Corbit wrote:
In any of these either misspellings, changes of names, ownership or
even structure over time render the obvious useless as keys. There
are
techniques for detecting and reducing duplication but the point is
that
for any of
On Thu, Jan 19, 2006 at 10:19:01AM -0800, Josh Berkus wrote:
One of the other most valuable targets for index-only access is the
many-to-many join table whose primary key consists of two (or more)
foreign keys to two (or more) other tables. It's actually not necessary
to check visibility
On Thu, Jan 19, 2006 at 10:35:30AM -0800, David Scott wrote:
Tom Lane wrote:
What sort of problems are you dealing with exactly? There has been
some discussion of changes that would improve certain scenarios. For
instance it might be plausible to do joins using index information and
only
On Thu, Jan 19, 2006 at 01:48:18PM -0600, Jim C. Nasby wrote:
On Thu, Jan 19, 2006 at 02:01:14PM -0500, [EMAIL PROTECTED] wrote:
On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate when you
Joshua D. Drake wrote:
Michael Paesold wrote:
You don't user pl/perl, do you -- i.e. I guess you read the latest
release notes and the thread here before that?
Yes I did. I didn't know that the person was running plPerl. I have
verified that they are. We are now going to check if upgrading
On Thu, Jan 19, 2006 at 02:46:11AM -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
But you couldn't make any meaningful changes in the definition of an
index, such as changing its column set, operator classes, partial-index
predicate, etc,
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
There is another possible answer, and it's something I've been
meaning to bring up for awhile. Is there a good reason why
postmaster is a symlink to postgres, rather than a hard link?
I don't know of one. Something I have thought
On Thu, Jan 19, 2006 at 10:09:26AM -0800, Josh Berkus wrote:
Martjin,
In any of these either misspellings, changes of names, ownership or
even structure over time render the obvious useless as keys. There are
techniques for detecting and reducing duplication but the point is that
for any of
Ühel kenal päeval, K, 2006-01-18 kell 22:35, kirjutas uwcssa:
I am testing the performance of postgresql on a set of workloads.
However,
the output significantly affects the performance evaluation. Is there
a way
to by-pass all output of select statements so the timing reflects only
the
I've completed a round of stress testing the system for vulnerabilities
to unexpected cache flush events (relcache, catcache, or typcache
entries disappearing while in use). I'm pleased to report that the 8.1
branch now passes all available regression tests (main, contrib, pl)
with
Michael Fuhr [EMAIL PROTECTED] writes:
On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa wrote:
I want to do this for repeating some experiment results, not for
tuning the db (pretty much like using an old machine to find
performance difference for an algorithm). so if i have a way
of
Jim C. Nasby [EMAIL PROTECTED] writes:
How would this affect changing the type of a column?
It doesn't, because we drop and rebuild indexes completely during ALTER
COLUMN TYPE.
regards, tom lane
---(end of broadcast)---
I want to do this for repeating some experiment results, not for
tuning the db (pretty much like using an old machine to find
performance difference for an algorithm). so if i have a way
of knowing which tables are storing the statistics, i guess i can
delete all from that table to archieve
Andrew - Supernews wrote:
src/backend/utils/adt/float.c:
/*
*drandom - returns a random number
*/
Datum
drandom(PG_FUNCTION_ARGS)
{
float8 result;
/* result 0.0-1.0 */
result = ((double) random()) / ((double) MAX_RANDOM_VALUE);
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
Do you still have that patch that folks could look at? ISTM that this
technique would be rather dependant on your actual workload, and as such
could result in a big win for certain types of queries.
It is not a patch, per se. It is a c language
Greetings,
I've got a fast FreeBSD/amd64 server available to run Buildfarm on.
However, I see we already have a couple of others running it.
My questions are:
1) do we need another one?
2) if yes, what options need coverage?
Thanks,
LER
--
Larry Rosenman
On Thu, Jan 19, 2006 at 11:46:29PM +0200, Hannu Krosing wrote:
??hel kenal p??eval, K, 2006-01-18 kell 22:35, kirjutas uwcssa:
I am testing the performance of postgresql on a set of workloads.
However,
the output significantly affects the performance evaluation. Is there
a way
to
Where are we on this? Rajesh, I think we are waiting for more
information from you.
---
R, Rajesh (STSD) wrote:
That was very much situation specific.
But the bottomline is the default test does not include netdb.h in
Fellow hacker,
I am new comer to postgres development community. Currently, I am
implementing tightly coupled machine classifiers within postgres. The
grammer looks like Train Parameter_list (class1,class2,class3...). I have
two major problems right now.
1. Train is a statement and it is
On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa wrote:
I want to do this for repeating some experiment results, not for
tuning the db (pretty much like using an old machine to find
performance difference for an algorithm). so if i have a way
of knowing which tables are storing the
On Thu, 2006-01-19 at 14:25 -0500, uwcssa wrote:
I have a simple question here, not sure if i should posted here but
if you have the quick answer, it helps a lot
i have a table that is already vacuumed. for some reason i want
to un-vacuum it instead of dropping the table and recreate the
On Thu, Jan 19, 2006 at 05:03:20PM -0500, Tom Lane wrote:
I'm still bothered by the likelihood that there are cache-flush bugs in
code paths that are not exercised by the regression tests. The
CLOBBER_CACHE patch is far too slow to consider enabling on any regular
basis, but it seems that
src/backend/utils/adt/float.c:
/*
* drandom - returns a random number
*/
Datum
drandom(PG_FUNCTION_ARGS)
{
float8 result;
/* result 0.0-1.0 */
result = ((double) random()) / ((double) MAX_RANDOM_VALUE);
PG_RETURN_FLOAT8(result);
}
On Wed, 2006-01-18 at 20:13 -0500, Tom Lane wrote:
Come to think of it, the idea also seems to map nicely into bitmap index
scans: the index will directly hand back a list of potential pages to
look at, but they are all marked lossy because the index doesn't know
exactly which tuple(s) on the
Bruce Momjian pgman@candle.pha.pa.us writes:
Because random returns a double, I think it is very possible that we
could return 1 due to rounding,
Not unless your machine has a double type with less than 32 bits of
precision, which seems pretty unlikely. It'd be sufficient to do
/*
Hi,
I'd like to get a general understanding of what kind of structures
PostgreSQL puts in shared memory and how they are managed. I'd like some
hints on where to start looking. Source, docs, prior discussions,
anything is considered helpful.
TIA,
Thomas Hallgren
Thomas Hallgren wrote:
Hi,
I'd like to get a general understanding of what kind of structures
PostgreSQL puts in shared memory and how they are managed. I'd like some
hints on where to start looking. Source, docs, prior discussions,
anything is considered helpful.
Have you looked on the
You could also do this by doing a filesystem copy of $PG_DATA (with
postgresql shut down), and then restoring that copy after your test. If
you used rsync (or something that allowed filesystem snapshots) this
probably wouldn't be very painful.
On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa
On Thu, Jan 19, 2006 at 02:50:39PM -0800, Jeremy Drake wrote:
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
Do you still have that patch that folks could look at? ISTM that this
technique would be rather dependant on your actual workload, and as such
could result in a big win for certain types
Simon Riggs [EMAIL PROTECTED] writes:
This seems to lead to a super-geometric progression in the number of
files required,
But we double the number of batches at each step, so there are going to
be at most 20 or so levels, and that's only assuming a *horridly* wrong
initial guess by the
Jim C. Nasby [EMAIL PROTECTED] writes:
Basically, numbers talk. If there were convincing numbers for something
that wasn't a corner-case that showed a marked improvement then there'd
be much more interest in getting this into the backend in some fashion.
I've got no doubt that there are *some*
On Tue, 2006-01-17 at 21:43 +, Simon Riggs wrote:
On Tue, 2006-01-17 at 09:52 -0500, Tom Lane wrote:
I was thinking along the lines of having multiple temp files per hash
bucket. If you have a tuple that needs to migrate from bucket M to
bucket N, you know that it arrived before every
On Thu, Jan 19, 2006 at 04:54:21PM -0600, Jim C. Nasby wrote:
You could also do this by doing a filesystem copy of $PG_DATA (with
postgresql shut down), and then restoring that copy after your test. If
you used rsync (or something that allowed filesystem snapshots) this
probably wouldn't be
Larry Rosenman [EMAIL PROTECTED] writes:
I've got a fast FreeBSD/amd64 server available to run Buildfarm on.
However, I see we already have a couple of others running it.
My questions are:
1) do we need another one?
2) if yes, what options need coverage?
Looks like
Yes. Representation of the DNA is probably best. But - that's a lot of
data to use as a key in multiple tables. :-)
No then you have problems with identical twins :)
Chris
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
Feel free to do whatever with this, it's pretty fast for tables where
seeks to validate tuples would hurt, but you do get back dead things...
How'd you then weed out the dead tuples?
I didn't get that far with it. The purpose of this function was
On Jan 20, 2006, at 10:50 , Christopher Kings-Lynne wrote:
Yes. Representation of the DNA is probably best. But - that's a
lot of
data to use as a key in multiple tables. :-)
No then you have problems with identical twins :)
And, looking forward, clones.
Michael Glaesemann
grzm
Fellow
hacker,I am new comer to postgres development community. Currently, I
am implementing tightly coupled machine classifiers within postgres. The
grammer looks like Train Parameter_list (class1,class2,class3...). I have
two major problems right now.1. Train is a statement
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I've got a fast FreeBSD/amd64 server available to run Buildfarm
on.
However, I see we already have a couple of others running it.
My questions are:
1) do we need another one?
2) if yes, what options need
Larry Rosenman ler@lerctr.org writes:
Tom Lane wrote:
Looks like we're fairly well covered on freebsd already. Are you
willing to consider running some less-popular OS on it?
What were you thinking?
[ shrug... ] Anything you don't see paired with amd64 on the buildfarm
roster is OK by me
76 matches
Mail list logo
