-Original Message-
From: Robert Treat [mailto:[EMAIL PROTECTED]
Sent: 12 October 2004 21:21
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PL/PgSQL for counting all rows in all tables.
Maybe I didn't phrase that quite right. How would a user know
that he needs to
On Sun, 2004-10-10 at 03:36, Chris Browne wrote:
There are doubtless cases where the optimizer won't use them where it
would be plausible to do so; that suggests, to me, possibilities for
enhancing the optimizer.
Speaking of which, if anyone has any examples of queries for which we
ought to be
The most nearly comparable thing is be the notion of partial
indexes, where, supposing you had 60 region codes (e.g. - 50 US
states, 10 Canadian provinces), you might set up indices thus:
For example, imagine you have a table on a dating website with 18 columns
representing 18 different
On K, 2004-10-13 at 00:09, Greg Stark wrote:
Josh Berkus [EMAIL PROTECTED] writes:
SELECT * FROM people WHERE orientation = 'gay' AND gender = 'male' AND city =
'San Francisco';
There are actually two TODOs here.
1) a bitmap scan that would be usable with any type of index. The tuple
Leeuw van der, Tim schrieb:
There are certainly cygwin-users trying out PostgreSQL on cygwin on
WinXX. If the newest cygwin-version will suddenly stop working under
WinXX, they will not be happy.
That's why we use cygwin symlinks, not junctions.
I've given consideration to the argument that you
Josh Berkus schrieb:
The most nearly comparable thing is be the notion of partial
indexes, where, supposing you had 60 region codes (e.g. - 50 US
states, 10 Canadian provinces), you might set up indices thus:
I'm afraid that you're mistaken about the functionality of bitmap indexes.
The purpose
Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] writes:
Workable examples for useful partitioned indexes, that help here are:
create index people_male_ix on people (city) where gender = 'male';
create index people_gay_ix on people (city) where orientation = 'gay';
create index people_male_gay_ix
Bruce Momjian schrieb:
Great, just glad we could get it all working. ...
Just that regression suite stopped working a while ago :(
That's by far more serious than the tiny build patches.
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00252.php
What kind of security restrictions do we want for prepared transactions?
Who has the right to finish a transaction that was started by user A? At
least the original user, I suppose, but who else?
Under what account is the transaction manager typically going to run? A
separate TM account
Having seen a couple recent reports of could not access status of
transaction for old, not-obviously-corrupt transaction numbers, I went
looking to see if I could find a way that the system could truncate CLOG
before it's really marked all occurrences of old transaction numbers as
known-dead or
Heikki Linnakangas [EMAIL PROTECTED] writes:
What kind of security restrictions do we want for prepared transactions?
Who has the right to finish a transaction that was started by user A? At
least the original user, I suppose, but who else?
I would say the original user, any superuser, and
Heikki Linnakangas wrote:
What kind of security restrictions do we want for prepared transactions?
Who has the right to finish a transaction that was started by user A? At
least the original user, I suppose, but who else?
Under what account is the transaction manager typically going to run? A
Andreas,
I think bitmap indexes do have valid use cases, but partitioned indexes
are really a wonderful feature with a lot of use cases,
Sure, no question. That's why we have them.
maybe including
this one.
Nope, not at all.
Workable examples for useful partitioned indexes, that help
Josh Berkus [EMAIL PROTECTED] writes:
BTW, Tom, I was talking to Sean last night and he was saying that our
current planner cost calculations assume that a 2-column index fetch
will be twice as expensive as a 1-column index fetch. Is this right?
No.
regards, tom lane
Marcos,
http://www.inf.puc-rio.br/~postgresql/
There you will find a link to a tutorial based description of the
hypothetical indexes feature we have implemented on PostgreSQL 7.4
beta 3.
I would love to see this as an add-in project on pgFoundry. Particularly
since your online
On Wed, Oct 13, 2004 at 11:58:21PM +0700, David Garamond wrote:
Heikki Linnakangas wrote:
Another approach I've been thinking about is to allow anyone that knows
the (user-supplied) global transaction identifier to finish the
transaction, and hide the gids of running transactions from
OK, I have applied the following patch that uses Cygwin native
symlink() instead of the Win32 junctions. The reason
for this is
that Cygwin symlinks work on Win95/98/ME where
junction points do
not
Is this really a Win95/98/ME vs NT distinction or a FAT32
vs NTFS
Heikki Linnakangas wrote:
What kind of security restrictions do we want for prepared
transactions? Who has the right to finish a transaction that was
started by user A? At least the original user, I suppose, but who
else?
Do we not require transaction initiation and conclusion to happen in
On Wed, 13 Oct 2004, Peter Eisentraut wrote:
Heikki Linnakangas wrote:
What kind of security restrictions do we want for prepared
transactions? Who has the right to finish a transaction that was
started by user A? At least the original user, I suppose, but who
else?
Do we not require transaction
So those URL's are all fixed? Would you post your remaining failures?
---
Reini Urban wrote:
Bruce Momjian schrieb:
Great, just glad we could get it all working. ...
Just that regression suite stopped working a while
Heikki Linnakangas wrote:
Another approach I've been thinking about is to allow anyone that knows
the (user-supplied) global transaction identifier to finish the
transaction, and hide the gids of running transactions from regular
users. That way, the gid acts as a secret token that's only known
Heikki,
Another approach I've been thinking about is to allow anyone that knows
the (user-supplied) global transaction identifier to finish the
transaction, and hide the gids of running transactions from regular users.
That way, the gid acts as a secret token that's only known by the
Hi,
Im new to postgres and I'm about to implement the algorithm double
pipelined hash join. I've started using SPI functions but soon I
realised that I 'm not at the right way (am I?). Is there a way that
I'm not obliged to change code of the optimizer of postgres but to
write a seperate
Martha Chronopoulou [EMAIL PROTECTED] writes:
Im new to postgres and I'm about to implement the algorithm double
pipelined hash join. I've started using SPI functions but soon I
realised that I 'm not at the right way (am I?).
Not even close. You need to be implementing new executor node
Alvaro Herrera wrote:
Another approach I've been thinking about is to allow anyone that knows
the (user-supplied) global transaction identifier to finish the
transaction, and hide the gids of running transactions from regular
users. That way, the gid acts as a secret token that's only known by
David Garamond wrote:
So it is possible for a user connected to the DB to send random commit
or cancel commands, just in case she happens to hit a valid GID?
It is not essentially different from someone trying to bruteforce a
password. A 128bit value like a random GUID is as strong as a 16 char
I have added the attached patch to allow Cygwin /contrib compiles. I am
a little confused why Cygwin requires -lpgport and no other platform
does, but it is in the Cygwin-specific section so we can always improve
it later if we find the cause.
Thanks.
Bruce Momjian schrieb:
I have added the attached patch to allow Cygwin /contrib compiles. I am
a little confused why Cygwin requires -lpgport and no other platform
does, but it is in the Cygwin-specific section so we can always improve
it later if we find the cause.
thanks. duplicate does not
28 matches
Mail list logo
