Qingqing,
Thanks for the info, I do know all issues you mentioned. I want to know
if there is any possibility to research performance problem in PostgreSQL
without voodoo techiques, at least at the level of pg itself. At this aspect,
I could answer myself: heap_blks_read is the # of blocks
'ordere
I'd like to propose that we abandon the name "PostgreSQL" and rename the
project "Postgre", to be pronounced either "post-greh" or "post-gree".
This change would have a twofold purpose: it would meet popular demand,
and it would reflect my next proposal, that we abandon SQL as the query
language an
Euler Taveira de Oliveira wrote:
Are you talking about DELETE FROM bar USING foo ? I submitted a patch
some months ago.
At a quick glance, looks pretty good. It needs regression tests, and I'd
also like to refactor the analyze.c additions to use the same code
UPDATE uses for the tlist transformat
Neil Conway wrote:
> Bruce Momjian wrote:
> > Wow, seems I lost that somehow.
>
> BTW, I personally think it is fine for patch submitters to send "ping"
> mails if your patch is not applied or reviewed within a reasonable
> period of time -- this is standard practice among the GCC community,
>
Bruce Momjian wrote:
Wow, seems I lost that somehow.
BTW, I personally think it is fine for patch submitters to send "ping"
mails if your patch is not applied or reviewed within a reasonable
period of time -- this is standard practice among the GCC community,
for example. I certainly have a ten
But half of the postgresql "functions" are in the grammar anyway -
they're not even listed.
Should we look at adding stub functions into pg_proc for \df display
somehow?
I'm not suggesting that at all. I was just pointing out that \df isn't
a useful view of 'what functions does postgresql have t
On Fri, Apr 01, 2005 at 12:59:43PM +0800, Christopher Kings-Lynne wrote:
>
> I only ever use \df to look at my own functions...
>
> I'd prefer if no system functions were listed :)
You can use, for example, "\df public." to see only those functions
in the public schema. That's what I do when I
On Fri, Apr 01, 2005 at 12:08:21AM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> >
> > What makes you think you can't call 'em from SQL?
> >
> > regression=# select int4in('345');
> > int4in
> >
> > 345
> > (1 row)
>
> Yes, I guess I mean does it make sense to call them from SQL
Christopher Kings-Lynne wrote:
> > I use df to see what functions are available. I want to see them all.
>
> But half of the postgresql "functions" are in the grammar anyway -
> they're not even listed.
Should we look at adding stub functions into pg_proc for \df display
somehow?
--
Bruce Mo
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What makes you think you can't call 'em from SQL?
>
> > Yes, I guess I mean does it make sense to call them from SQL? Their
> > purpose is for internal use, no?
>
> People have actually used them for purposes of cross-type convers
I use df to see what functions are available. I want to see them all.
But half of the postgresql "functions" are in the grammar anyway -
they're not even listed.
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
I use df to see what functions are available. I want to see them all.
--elein
On Fri, Apr 01, 2005 at 12:59:43PM +0800, Christopher Kings-Lynne wrote:
> >Uh, who exactly agreed to that? I know when I do \df it's generally
> >to check out built-in functions not my own. I don't see this as an
> >
Bruce Momjian writes:
> Tom Lane wrote:
>> What makes you think you can't call 'em from SQL?
> Yes, I guess I mean does it make sense to call them from SQL? Their
> purpose is for internal use, no?
People have actually used them for purposes of cross-type conversion
where there's I/O compatibil
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We could fix it by changing <> to IS DISTINCT FROM ... but I've never
> >> been very happy with the idea that \df tries to suppress I/O functions
> >> anyway. How do you feel about removing the cstring test altogether?
>
> > I like
Bruce Momjian writes:
> Tom Lane wrote:
>> We could fix it by changing <> to IS DISTINCT FROM ... but I've never
>> been very happy with the idea that \df tries to suppress I/O functions
>> anyway. How do you feel about removing the cstring test altogether?
> I like the cstring test. I don't th
Uh, who exactly agreed to that? I know when I do \df it's generally
to check out built-in functions not my own. I don't see this as an
improvement.
I only ever use \df to look at my own functions...
I'd prefer if no system functions were listed :)
Chris
---(end of broadcas
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The problem appears to be that proargtypes[0] is now NULL instead
> > of 0. Here's a simplified version of the \df query:
>
> > SELECT proname
> > FROM pg_catalog.pg_proc p
> > WHERE p.proargtypes[0] <> 'pg_catalog.cstring'::pg_
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> This could work out well with my upcoming patch to have \df only
> show non-system functions. Since the user will in the future have
> to explicitly call \dfS to see the system functions, 60 extra
> out of 1700 should not matter too much.
Uh, who
There is an updated survey of open source developers:
http://flosspols.org/survey/survey_part.php?groupid=sd
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I don't think that's a bug. You may not intend ever to cluster on that
index again, and if you try it will tell you about the problem.
Except it breaks the 'cluster everything' case:
test=# cluster;
ERROR: cannot cluster when index access method does not handle null values
HINT: You may be able
"Tom Lane" <[EMAIL PROTECTED]> writes
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > On Monday 21 March 2005 11:40 am, Tom Lane wrote:
> >> However, given that there are 9334 tuples in 82282 pages, I'd say
> >> that autovacuum has already failed Steve rather badly :-(. There
> >> shouldn't be m
On Thu, Mar 31, 2005 at 06:54:31PM -0600, Guy Rouillier wrote:
> Alvaro Herrera wrote:
> >
> > Now this can't be applied right away because it's easy to run "out of
> > memory" (shared memory for the lock table). Say, a delete or update
> > that touches 1 tuples does not work. I'm currently
On Thu, Mar 31, 2005 at 12:03:37AM -0500, Tom Lane wrote:
> > Right; I was planning to bail and only do this for inner joins.
>
> Well, for outer joins the optimal strategy is simple: pull from the
> outer query first. If it's empty then you needn't touch the inner
> query at all. Otherwise you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Wouldn't bother me -- I'd rather see what's there and make the
> "uninteresting" call myself, if that's the only reason for not
> showing the I/O functions. It's not like they'd overwhelm the
> output.
This could work out well with my upcoming pa
Steve Crawford <[EMAIL PROTECTED]> writes:
> On Thursday 31 March 2005 12:06 pm, Tom Lane wrote:
>> Steve, is your app in the habit of creating lots of temp tables
>> that are not dropped explicitly? That would explain why you are
>> getting bit more than other people.
> Yes, various processes cr
Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
However, given that there are 9334 tuples in 82282 pages, I'd say
that autovacuum has already failed Steve rather badly :-(. There
shouldn't be more than a couple hundred pages give
On Thursday 31 March 2005 12:06 pm, Tom Lane wrote:
> I wrote:
> > The light just went on ... system catalog updates don't generate
> > statistics reports. Hence, autovacuum doesn't know any work is
> > needed.
>
> The above claim is too strong --- they do normally generate stats
> updates. Howev
On Thu, Mar 31, 2005 at 12:19:08AM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > We have a problem as soon as somebody tries to delete a lot of rows from
> > a big table. We cannot possibly extend the memory requirements forever,
> > so we need to spill to disk without ha
I wrote:
> The light just went on ... system catalog updates don't generate
> statistics reports. Hence, autovacuum doesn't know any work is needed.
The above claim is too strong --- they do normally generate stats
updates. However, in a simple test I observed that
pg_stat_all_tables.n_tup_del d
Alvaro Herrera wrote:
On Thu, Mar 31, 2005 at 07:14:25PM +0100, Peter Eisentraut wrote:
Log Message:
---
Translation updates
Are we going to use the translation project on pgFoundry? I registered
a project 3 days ago for doing it, but it hasn't been approved yet.
It has now.
ch
Alvaro Herrera wrote:
> Are we going to use the translation project on pgFoundry? I
> registered a project 3 days ago for doing it, but it hasn't been
> approved yet.
The project has already been registered weeks ago (pgtranslation).
Please don't register another one.
I plan to handle translat
Steve Crawford <[EMAIL PROTECTED]> writes:
> On Monday 21 March 2005 11:40 am, Tom Lane wrote:
>> However, given that there are 9334 tuples in 82282 pages, I'd say
>> that autovacuum has already failed Steve rather badly :-(. There
>> shouldn't be more than a couple hundred pages given that number
On Thu, Mar 31, 2005 at 07:14:25PM +0100, Peter Eisentraut wrote:
> Log Message:
> ---
> Translation updates
Are we going to use the translation project on pgFoundry? I registered
a project 3 days ago for doing it, but it hasn't been approved yet.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
On Thu, Mar 31, 2005 at 01:06:39AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The problem appears to be that proargtypes[0] is now NULL instead
> > of 0. Here's a simplified version of the \df query:
>
> > SELECT proname
> > FROM pg_catalog.pg_proc p
> > WHERE p.p
Euler Taveira de Oliveira wrote:
> Hi,
>
> > > I'd like to make add_missing_from=false the default for 8.1. Any
> > objections?
> >
> > We still don't have a solution for DELETE, do we?
> >
> Are you talking about DELETE FROM bar USING foo ? I submitted a patch
> some months ago.
> http://archiv
Hi,
> > I'd like to make add_missing_from=false the default for 8.1. Any
> objections?
>
> We still don't have a solution for DELETE, do we?
>
Are you talking about DELETE FROM bar USING foo ? I submitted a patch
some months ago.
http://archives.postgresql.org/pgsql-patches/2004-12/msg00169.php
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now I remember that in the WAL docs there is a paragraph or two
> mentioning that in a future project we want to implement UNDO ... maybe
> it's a good idea to rip that off.
It is gone as of 8.0.
regards, tom lane
-
On Thu, Mar 31, 2005 at 05:07:39PM +0100, Simon Riggs wrote:
> On Sun, 2005-03-27 at 16:01 -0500, Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > So I think this is dead code. The attached patch removes it.
> >
> > Yeah, it is dead code; it's a leftover from Vadim's old plan
On Sun, 2005-03-27 at 16:01 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So I think this is dead code. The attached patch removes it.
>
> Yeah, it is dead code; it's a leftover from Vadim's old plan to implement
> Oracle-style UNDO. AFAIK none of the current crop of ha
I found several unpleasant blot in comparing functions and commit changes to
7.4, 8.0 and head. Pls check (it need just to recompile .so file)
Christopher Kings-Lynne wrote:
It's cached. This select should run only one time per connection for
each used dictionary. If its'not then it's a bug. I'l
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> You can drop a NOT NULL on a column, even if that column is part of an
>> index that is clustered, where the index does not index NULLs.
I don't think that's a bug. You may not intend ever to cluster on that
index again, and if you try it wi
On Thu, Mar 31, 2005 at 12:37:22PM +0100, Simon Riggs wrote:
> On Thu, 2005-03-31 at 13:35 +0530, shingav wrote:
> > But I fail to understand how data is stored (written) in the
> > "01x" file. I came across some CRC and compression code.
> >
> > I used a hexeditor to deciphar the content
"Oleg Bartunov" writes
> From my experiments I feel heap_blks_read is the table blocks read from
disk,
> well, sort of, and heap_blks_hit - from buffer. At least, I observed when
I
> repeat the same query several times (heap_blks_read+heap_blks_hit) doesn't
> changed while more blocks come from h
Sorry, was in a rush before. I still don't have time to fix this for
8.0.2, so that's why I rushed out the report. Here is a full description...
You can drop a NOT NULL on a column, even if that column is part of an
index that is clustered, where the index does not index NULLs.
First, install
On Thu, 2005-03-31 at 13:35 +0530, shingav wrote:
> I am trying to understand the way in which PostgreSQL creates, updates
> and uses the transaction log.
If you say why, we might be able to help.
> I browsed through the sources and what I understand is that, when we
> "initdb", the "initdb" bina
It's cached. This select should run only one time per connection for
each used dictionary. If its'not then it's a bug. I'll check it.
It probably is then - although I do use a persistent connection pool,
but I wouldn't have thought that'd use more than a new connection every
once in a while?
Ch
On Thu, 31 Mar 2005, Marian POPESCU wrote:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> >
> >>FYI, IBM has applied for a patent on ARC (AFAICS the patent application
> >>is still pending, although the USPTO site is a little hard to grok):
> >
> >
> >>http://appft1.uspto.gov/neta
Christopher Kings-Lynne wrote:
I see this in my PQA analyzed PostgreSQL log:
Slowest queries
select dict_init, dict_initoption, dict_lexize from pg_ts_dict where oid
= $1
It's my number one slowest query apparently!
Can that lookup perhaps be cached in some way?
It's cached. This select
You can drop a NOT NULL on a column, even if that column is part of an
index that is clustered, where the index does not index NULLs.
Also, I dont think that ALTER TABLE blah CLUSTER ON foo; actually warns
about clustering a non-null indexing index. However, CLUSTER foo ON
blah; does.
Chris
-
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
>>FYI, IBM has applied for a patent on ARC (AFAICS the patent application
>>is still pending, although the USPTO site is a little hard to grok):
>
>
>>http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fne
Hello,
I am trying to understand the way in which PostgreSQL creates, updates
and uses the transaction log.
I browsed through the sources and what I understand is that, when we
"initdb", the "initdb" binary reads postgres.bki which is created by
genbki.sh.
But I fail to understand how data is st
51 matches
Mail list logo
