Although this is all true, consider that adding hints will mean that the
Pg developers *never* get bug reports to drive the optimizer improvement
process. This will have the effect of stagnating its development. I
think this would be a bad thing :-)
As an aside note that DB2 UDB does not let you hi
Neil Conway <[EMAIL PROTECTED]> writes:
> - good, thorough documentation of the internals (naturally this would
> help attract OSS developers as well)
I don't know what software you work with but the Postgres source is far and
away the best documented source I've had the pleasure to read. I thin
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-
Bruce Momjian writes:
> And ARC has locking requirements that will make it very hard to fix our
> SMP buffer management problems in 8.1.
I am working on a buffer manager rewrite using the BufMgrLock breakup
and "clock sweep" management algorithm we've been discussing. At the
moment it's passing
I will be on Boston for Linuxworld from Tuesday through Thursday. I
will read email only occasionally.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Chri
> [EMAIL PROTECTED] writes:
>> I think that is sort of arrogant. Look at Oracle, you can give the
>> planner
>> hints in the form of comments.
>
> Arrogant or not, that's the general view of the people who work on the
> planner.
>
> The real issue is not so much whether the planner will always get
On Mon, 2005-02-14 at 22:56 -0500, Bruce Momjian wrote:
> And the user maintenance of updating those hints for every release of
> PostgreSQL as we improve the database engine.
... and maintaining those hints as the data changes over time.
But I think this thread has been hijacked toward a subject
This has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
ITAGAKI Takahiro wrote:
> Hello everyone.
>
> I fixed two bugs in the patch that I sent before.
> Check and test new one
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > Might it be possible to contact IBM directly and ask if they will allow
> > usage of the patent for PostgreSQL. They've let 500 patents for open
> > source, maybe they'll give a write off for this as well.
>
> If there were hard evidence that the ARC
This has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
John Hansen wrote:
> Hi list,
>
>
> Attached for your perusal, unicode versions of upper/lower, that work
> independent
[EMAIL PROTECTED] writes:
> Might it be possible to contact IBM directly and ask if they will allow
> usage of the patent for PostgreSQL. They've let 500 patents for open
> source, maybe they'll give a write off for this as well.
If there were hard evidence that the ARC algorithm was far better th
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I think that is sort of arrogant. Look at Oracle, you can give the planner
> > hints in the form of comments.
>
> Arrogant or not, that's the general view of the people who work on the
> planner.
>
> The real issue is not so much whether the planner
[EMAIL PROTECTED] writes:
> I think that is sort of arrogant. Look at Oracle, you can give the planner
> hints in the form of comments.
Arrogant or not, that's the general view of the people who work on the
planner.
The real issue is not so much whether the planner will always get things
right --
On Mon, 2005-02-14 at 17:02 +0500, Sibtay Abbas wrote:
> thank you for the detailed reply
> But what i wanted to know is that how can we actually get a function's
> oid from its
> name from within postgresql code itself
You'll want to query the syscache. Note that due to function
overloading, ther
Manfred Koizar wrote:
> On Wed, 19 Jan 2005 18:57:48 +0100, I wrote:
> > My first vacuum.c
> >refactoring patch, rev 1.281 2004-06-08, added these comments in
> >repair_frag():
> >
> >/*
> > * VACUUM FULL has an exclusive lock on the relation. So
> > * normally no other transaction can have pendi
I have added this syntax to the TODO list:
* Allow GRANT/REVOKE permissions to be applied to all schema objects with one
command
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
---
Abhijit Menon-Sen wrote:
> At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote:
> >
> > Should our multi-byte encoding be referred to as UTF8 or Unicode?
>
> The *encoding* should certainly be referred to as UTF-8. Unicode is a
> character set, not an encoding; Unicode characters may be enc
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >[EMAIL PROTECTED] wrote:
> >
> >
> >>Might it be possible to contact IBM directly and ask if they will allow
> >>usage of the patent for PostgreSQL. They've let 500 patents for open
> >>source, maybe they'll give a write off for this as well.
>
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-w
At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote:
>
> Should our multi-byte encoding be referred to as UTF8 or Unicode?
The *encoding* should certainly be referred to as UTF-8. Unicode is a
character set, not an encoding; Unicode characters may be encoded with
UTF-8, among other things.
> [EMAIL PROTECTED] wrote:
>> Might it be possible to contact IBM directly and ask if they will allow
>> usage of the patent for PostgreSQL. They've let 500 patents for open
>> source, maybe they'll give a write off for this as well.
>>
>> There is an advantage beyond just not having to re-write th
Should our multi-byte encoding be referred to as UTF8 or Unicode?
I know UTF8 is a type of unicode but do we need to rename anything from
Unicode to UTF8?
Someone asked me via private email.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
[EMAIL PROTECTED] wrote:
> Might it be possible to contact IBM directly and ask if they will allow
> usage of the patent for PostgreSQL. They've let 500 patents for open
> source, maybe they'll give a write off for this as well.
>
> There is an advantage beyond just not having to re-write the code
Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.
There is an advantage beyond just not having to re-write the code, but it
would also be sort of an I
This thread has been saved for the 8.1 release:
http://momjian.postgresql.org/cgi-bin/pgpatches2
---
ITAGAKI Takahiro wrote:
> Hello, all.
>
> I think that there is room for improvement in WAL.
> Here is a patch f
FYI, core has discussed the pending IBM ARC patent and the usage of
those ideas in 8.0.
Tom has found a 2Q cache algorithm that predates the ARC patent and is
very similar to ARC. The major difference is that it doesn't auto-size
the ARC sub-buffers.
Core believes it is best to backpatch this
Beautiful, just what I was looking for.
Thnx,
John
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 15, 2005 6:31 AM
> To: Michael Fuhr
> Cc: John Hansen; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Schema name of function
>
> Michael
> On Thu, 2005-02-10 at 14:37 -0500, Bruce Momjian wrote:
>> No, we feel that is of limited value. If the optimizer isn't doing
>> things properly, we will fix it.
>
> I agree that improving the optimizer is the right answer for normal
> usage, so I can't get excited about query-level plan hints,
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> This might seem like a stupid question, but since this is a massive data
> loss potential in PostgreSQL, what's so hard about having the
> checkpointer or something check the transaction counter when it runs and
> either issue a db-wide vac
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Feb 14, 2005 at 11:11:53AM -0500, Tom Lane wrote:
>> In C, it'd be a lot easier (and faster) to do a couple of SearchSysCache
>> calls than to use SPI to get those rows.
> The following appears to work -- does it look right, aside from the
> missi
On Mon, Feb 14, 2005 at 05:02:19PM +0500, Sibtay Abbas wrote:
>
> Actually i ve introduced a new statement in plpgsql, that supports calling
> a plpgsql function from within a plpgsql function for example
>
> CALL function_name( );
How would this differ from PERFORM?
--
Michael Fuhr
http://www
On Mon, Feb 14, 2005 at 11:11:53AM -0500, Tom Lane wrote:
>
> In C, it'd be a lot easier (and faster) to do a couple of SearchSysCache
> calls than to use SPI to get those rows.
The following appears to work -- does it look right, aside from the
missing error checking?
tuple = SearchSysCache(P
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> This might seem like a stupid question, but since this is a massive
> data loss potential in PostgreSQL, what's so hard about having the
> checkpointer or something check the transaction counter when it runs
> and either issue a db-wide vacuum
>> I think you're pretty well screwed as far as getting it *all* back goes,
>> but you could use pg_resetxlog to back up the NextXID counter enough to
>> make your tables and databases reappear (and thereby lose the effects of
>> however many recent transactions you back up over).
>>
>> Once you've
It must be possible to create a tool based on the PostgreSQL sources that
can read all the tuples in a database and dump them to a file stream. All
the data remains in the file until overwritten with data after a vacuum.
It *should* be doable.
If there data in the table is worth anything, then it
[EMAIL PROTECTED] wrote:
You know, I don't think a lot of people "get" the issues I was describing,
or maybe they don't believe it, I don't know, but, I think that it would
be a useful contrib project to create an 'analyze_special('table',
'column', 'method')' function that does a better job at cal
I think you're pretty well screwed as far as getting it *all* back goes,
but you could use pg_resetxlog to back up the NextXID counter enough to
make your tables and databases reappear (and thereby lose the effects of
however many recent transactions you back up over).
Once you've found a NextXID s
> Once you've found a NextXID setting you like, I'd suggest an immediate
> pg_dumpall/initdb/reload to make sure you have a consistent set of data.
> Don't VACUUM, or indeed modify the DB at all, until you have gotten a
> satisfactory dump.
>
> Then put in a cron job to do periodic vacuuming ;-)
T
"Kouber Saparev" <[EMAIL PROTECTED]> writes:
> After asking the guys in the [EMAIL PROTECTED] channel they told
> me that the reason is the "Transaction ID wraparound", because I have never
> ran VACUUM on the whole database.
> So they proposed to ask here for help. I have stopped the server, but
8.0.X will have proper filename reporting for rmtree() failures.
---
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
> >> printed out
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Feb 14, 2005 at 07:32:15PM +1100, John Hansen wrote:
>> Is there a way for a C function to determine the name of the
>> schema in which is was created?
> Dunno if there's anything as simple as whats_my_schema(), but
> fcinfo->flinfo->fn_oid should
> Probably off-topic, but I think it's worth to see what astronomers are
> doing with their very big spatial databases. For example, we are working
> with more than 500,000,000 rows catalog and we use some special
> transformation
> of coordinates to integer numbers with preserving objects closenes
thank you for the detailed reply
But what i wanted to know is that how can we actually get a function's
oid from its
name from within postgresql code itself
Actually i ve introduced a new statement in plpgsql, that supports calling
a plpgsql function from within a plpgsql function for example
CAL
Hi folks,
I ran into big trouble - it seems that my DB is lost.
"select * from pg_database" gives me 0 rows, but I still can connect to
databases with \c and even select from tables there, although they're also
not visible with \dt.
After asking the guys in the [EMAIL PROTECTED] channel they tol
Richard Huxton wrote:
Oliver Jowett wrote:
I'm currently trying to find a clean way to deal with network-dead
clients that are in a transaction and holding locks etc.
Have you come across the pgpool connection-pooling project?
http://pgpool.projects.postgresql.org/
I've looked at it, haven't use
On Mon, Feb 14, 2005 at 07:32:15PM +1100, John Hansen wrote:
>
> Is there a way for a C function to determine the name of the
> schema in which is was created?
Dunno if there's anything as simple as whats_my_schema(), but
fcinfo->flinfo->fn_oid should contain the function's oid. If nobody
mentio
Oliver Jowett wrote:
I'm currently trying to find a clean way to deal with network-dead
clients that are in a transaction and holding locks etc.
The normal "client closes socket" case works fine. The scenario I'm
worried about is when the client machine falls off the network entirely
for some r
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> and changing the buf_table hash table. The only common
Tom> operation that needs exclusive lock is reading in a page that
Tom> was not in shared buffers already, which will require at
Tom> least a kernel call and usually a w
Just got reminded...
Is there a way for a C function to determine the name of the schema in which is
was created?
... John
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Mon, Feb 14, 2005 at 12:47:44PM +0500, Sibtay Abbas wrote:
>
> Is it possible to get the oid of a function on the basis of its name?.
One way is to cast the function name to regproc (or, with arguments,
to regprocedure) and then to oid:
SELECT 'atan'::regproc::oid;
SELECT 'length(text)'::regp
50 matches
Mail list logo
