Robert Haas wrote:
> On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
> wrote:
> > After playing with this in benchmarks and researching the weird results I
> > got I'm going to advise dropping the todo for now unless something happens
> > to change how postgres handles clustering.
>
> I agree, let'
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
wrote:
> After playing with this in benchmarks and researching the weird results I
> got I'm going to advise dropping the todo for now unless something happens
> to change how postgres handles clustering.
I agree, let's remove it.
That having been sa
After playing with this in benchmarks and researching the weird results I
got I'm going to advise dropping the todo for now unless something happens
to change how postgres handles clustering. You guys probably already
grokked this so I am just recording it for the list archives.
The primary
On Wed, Jan 19, 2011 at 4:27 PM, Simone Aiken wrote:
> In my experience size increases related to documentation are almost always
> worth it. So I'm prejudiced right out of the gate. I was wondering if
> every pg_ table gets copied out to every database .. if there is already a
> mechanism for
>
>I seem to recall some muttering about teaching genbki to extract such
comments from the SGML sources or perhaps the C header files. I tend to
agree though that it would be a lot >more work than it's worth. And as you
say, pg_description entries aren't free.
>
I know I can't do all of the wor
Robert Haas writes:
> On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
>> Well, on my machine pg_description is about 210K (per database) as of
>> HEAD. 90% of its contents are pg_proc entries, though I have no good
>> fix on how much of that is for internal-use-only functions. A very
>> rough
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>>> Which brings up another point though. I have a personal TODO item to
>>> make the comments for operator support functions more consistent:
>>> http://archives.postgresql
Robert Haas writes:
> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>> Which brings up another point though. I have a personal TODO item to
>> make the comments for operator support functions more consistent:
>> http://archives.postgresql.org/message-id/21407.1287157...@sss.pgh.pa.us
>> Should
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
>> wrote:
>>> Pages like this one have column comments for the system tables:
>>>
>>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
>
>> Oh, I see. I don't think we
Excerpts from Robert Haas's message of mié ene 19 15:25:00 -0300 2011:
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for keeping the two places in sync.
Maybe autogenerate both the .sgml and the postgres.description files
from a single source.
> And there'd be
Robert Haas writes:
> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
> wrote:
>> Pages like this one have column comments for the system tables:
>>
>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for ke
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
wrote:
> Pages like this one have column comments for the system tables:
>
> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
Oh, I see. I don't think we want to go there. We'd need some kind of
system for keeping the two places in sync. An
> Robert
>
> I think the first
> thing to do would be to try to come up with a reproducible test case
> where clustering the tables improves performance.
>
On that note, is there any standard way you guys do benchmarks?
> Bruce
>
>I think CLUSTER is a win when you are looking up multiple
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, January 18, 2011 2:53 PM
To: Simone Aiken
Cc: Alvaro Herrera; pgsql-hackers
Subject: Re: [HACKERS] ToDo List Item - System Table Index Clustering
>Sure - my point is just that we usually have a
On Tue, Jan 18, 2011 at 12:16 PM, Simone Aiken wrote:
> When I'm learning a new system I like to first learn how to use it,
> second learn its data model, third start seriously looking at the code.
> So that Todo is ideal for my learning method.
Sure - my point is just that we usually have as a c
Robert Haas wrote:
> On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
> wrote:
> > Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
> >>
> >> Hello Postgres Hackers,
> >>
> >> In reference to this todo item about clustering system table indexes,
> >> ( http://archives.postgre
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
wrote:
>> Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>>>
>> >Hello Postgres Hackers,
>>>
>> >In reference to this todo item about clustering system table indexes,
>>> ( http://archives.postgresql.org/pgsql-hackers/2004
On Jan 18, 2011, at 6:35 AM, Alvaro Herrera wrote:
>>
>
> Wow, this is really old stuff. I don't know if this is really of any
> benefit, given that these catalogs are loaded into syscaches anyway.
The benefit is educational primarily. I was looking for a todo list item
that would expose me
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
wrote:
> Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>>
>> Hello Postgres Hackers,
>>
>> In reference to this todo item about clustering system table indexes,
>> ( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>
> Hello Postgres Hackers,
BTW whatever you do, don't start a new thread by replying to an existing
message and just changing the subject line. It will mess up the
threading for some readers, and some might not even see you
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>
> Hello Postgres Hackers,
>
> In reference to this todo item about clustering system table indexes,
>
> ( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
> I have been studying the system ta
Followup on System Table Index clustering ToDo -
It looks like to implement this I need to do the following:
1 - Add statements to indexing.h to cluster the selected indexes.
A do-nothing define at the top to suppress warnings and then
lines below for perl to pars
>> Select typoutput::oid from pg_type limit 1;
> Also, you *can* go back the other way. It's very common to write
>
> Select * from pg_proc where oid = 'boolout'::regproc
>
> rather than looking up the OID first.
> see "Object Identifier Types" in the manual.
Many thanks
Nicolas Barbier writes:
> 2011/1/16 Simone Aiken :
>>... So even though the documentation says that column
>>maps to pg_proc.oid I can't then write:
>>Select * from pg_proc where oid = 'boolout';
> Type type of typoutput is "regproc", which is really an oid with a
2011/1/16 Simone Aiken :
> is there a way to make queries on the system tables show me what
> is actually there when I'm poking around? So for example:
>
> Select * from pg_type limit 1;
>
> tells me that the typoutput is 'boolout'. An english string rather
>
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
I have been studying the system tables to see which would benefit from
clustering. I have some index suggestions and a
26 matches
Mail list logo
