Bruce Momjian wrote:
> Tom Lane wrote:
>
>>Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>>OK, time to get moving folks. Looks like the increase in the function
>>>args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
>>
>>I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shou
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I've committed changes to do the following:
> o Fix buffer overrun possibilities in date/time handling
> o Handle fixed-length char and bit literals
> o Implement IS OF type predicate
> o Define macros to manipulate date/time typmod values
> o Map hex
I've committed changes to do the following:
o Fix buffer overrun possibilities in date/time handling
o Handle fixed-length char and bit literals
o Implement IS OF type predicate
o Define macros to manipulate date/time typmod values
o Map hex string literals to bit string type (may change later)
o
On Sat, 3 Aug 2002, Joe Conway wrote:
> I couldn't keep up with the list traffic this week, but I thought I saw
> enough to convince me that after it was all said and done, I would still
> be able to do `cvs co pgsql`. I'm finding today that after using cvsup
> to sync up, I can no longer checkou
Bruce Momjian wrote:
> Tom Lane wrote:
>>I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
>>too much. But have we done equivalent checks on NAMEDATALEN? In
>>particular, do we know what it does to the size of template1?
> No, I thought we saw the number, was 30%? No, we di
On 3 Aug 2002, Hannu Krosing wrote:
> hannu=# create table animal (name text, legcount int);
> CREATE
> hannu=# insert into animal values('pig',4);
> INSERT 34183 1
> hannu=# select * from animal;
> name | legcount
> --+--
> pig |4
> (1 row)
>
> hannu=# create table bird (w
On 29 Jul 2002, Stephen Deasey wrote:
> Table inheritance offers data model extensibility. New (derived) tables
> can be added to the system, and will work with existing code that
> opperates on the base tables, without having to hack up all the code.
And why does this not work with the standar
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Also, is there any value to contrib/fulltextindex now that we have
>> contrib/tsearch?
> I haven't looked at tsearch yet, but I expect it's way better than
> fulltextindex. However there's more than a few of us using fulltextindex,
> so I
> Yes, I have always liked CLUSTER with full text searches because you are
> usually hitting multiple rows with a single equaltiy restriction, and
> CLUSTER puts all the hits on the same page.
>
> If you look in contrib/fulltextindex, you will see mention of CLUSTER in
> the README. It may make s
Patch applied. Thanks.
---
Oleg Bartunov wrote:
> Bruce,
>
> please find attached patch to current CVS ( contrib/ltree )
>
> Changes:
>
> July 31, 2002
>Now works on 64-bit platforms.
>Added function lca - low
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> That makes me wonder: should I produce some regression tests for
> CLUSTER?
It'd be a good thing.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comm
Patch rejected. Tom Lane pointed out some mistakes in this patch, and
the patch does not show any corrections.
---
eutm wrote:
>Some weeks ago i wrote about one problem(called as
> "Bug of PL/pgSQL parser"):
>
> "eut
On 3 Aug 2002, Hannu Krosing wrote:
> On Sat, 2002-08-03 at 16:32, Curt Sampson wrote:
> > On 2 Aug 2002, Hannu Krosing wrote:
> >
> > Perhaps this is the problem. I disagree that it's a "higher" level.
>
> I don't mean "morally higher" ;)
> Just more concise and easier to grasp, same as VIEW vs
Peter Eisentraut dijo:
> Neil Conway writes:
>
> > The attached patch implements START TRANSACTION, per SQL99. The
> > functionality of the command is basically identical to that of
> > BEGIN; it just accepts a few extra options (only one of which
> > PostgreSQL currently implements), and is st
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sorry, I mean pg_backend_pid.
Okay, I was unsure if that was a typo or not.
> I could expose backend_id but it may
> confuse people so pid is probably better. If you had the id, you could
> use pg_stat_get_backend_pid() to get the pid.
Yeah, I though
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, should we be updating that flag after we CLUSTER instead of
> requiring an ANALYZE after the CLUSTER?
Could do that I suppose, but I'm not super-excited about it. ANALYZE is
quite cheap these days (especially in comparison to CLUSTER ;-)). I'd
se
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Let's take it out and wait to see if anyone really still wants it.
>
> > Just when I am ready to throw it away, I come up with a use for the
> > function:
>
> > test=> select * from pg_stat_activity where procpid != backend_pid
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Sat, 3 Aug 2002, Tom Lane wrote:
>> AFAICT you're assuming that the table is *exactly* ordered by the
>> clustered attribute. While this is true at the instant CLUSTER
>> completes, the exact ordering will be destroyed by the first insert or
>> update
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Let's take it out and wait to see if anyone really still wants it.
> Just when I am ready to throw it away, I come up with a use for the
> function:
> test=> select * from pg_stat_activity where procpid != backend_pid();
> This shows all activi
Gavin Sherry wrote:
> > Gavin, is that a big win compared to just using the index and looping
> > through the entries, knowing that the index matches are on the same
> > page, and the heap matches are on the same page.
>
> Bruce,
>
> It would cut out the index over head. Besides at (1) (above) w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, should we be updating that flag after we CLUSTER instead of
> > requiring an ANALYZE after the CLUSTER?
>
> Could do that I suppose, but I'm not super-excited about it. ANALYZE is
> quite cheap these days (especially in compari
On Sat, 3 Aug 2002, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > Hi all,
> >
> > It occured to me on the plane home that now that CLUSTER is fixed we may
> > be able to put pg_index.indisclustered to use. If CLUSTER was to set
> > indisclustered to true when it clusters a heap according to the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As I remember, most cases where people have recently been asking for
> > backend pid were related to temp tables because they were named by pid.
>
> Ah, good point.
>
> > I don't think they are anymore. (?)
>
> Check.
>
> > We c
Gavin Sherry wrote:
> Hi all,
>
> It occured to me on the plane home that now that CLUSTER is fixed we may
> be able to put pg_index.indisclustered to use. If CLUSTER was to set
> indisclustered to true when it clusters a heap according to the given
> index, we could speed up sequantial scans. Th
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > It occured to me on the plane home that now that CLUSTER is fixed we may
> > be able to put pg_index.indisclustered to use. If CLUSTER was to set
> > indisclustered to true when it clusters a heap according to the given
> > index, we c
On Sat, 3 Aug 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > It occured to me on the plane home that now that CLUSTER is fixed we may
> > be able to put pg_index.indisclustered to use. If CLUSTER was to set
> > indisclustered to true when it clusters a heap according to the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, time to get moving folks. Looks like the increase in the function
> > args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
>
> I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
> too much. But
Sounds like a win all around; make PITR easier and temp tables faster.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > There is debate on whether the local buffers are even valuable
> > considering the
Gavin Sherry <[EMAIL PROTECTED]> writes:
> It occured to me on the plane home that now that CLUSTER is fixed we may
> be able to put pg_index.indisclustered to use. If CLUSTER was to set
> indisclustered to true when it clusters a heap according to the given
> index, we could speed up sequantial s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As I remember, most cases where people have recently been asking for
> backend pid were related to temp tables because they were named by pid.
Ah, good point.
> I don't think they are anymore. (?)
Check.
> We can do two things. We can either renam
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, time to get moving folks. Looks like the increase in the function
> args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
too much. But have we done equivalent che
Bruce Momjian <[EMAIL PROTECTED]> writes:
> There is debate on whether the local buffers are even valuable
> considering the headache they cause in other parts of the system.
More specifically, the issue is that when (if) you commit, the contents
of the new table now have to be pushed out to shar
Hi all,
It occured to me on the plane home that now that CLUSTER is fixed we may
be able to put pg_index.indisclustered to use. If CLUSTER was to set
indisclustered to true when it clusters a heap according to the given
index, we could speed up sequantial scans. There are two possible ways.
1) P
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Lack of btree index support for _oid would be the first hurdle.
> Is that index really needed, or is it there just to enforce uniqueness ?
Both.
> Also, (imho ;) btree index support should be done for all array types
> which have comparison ops for e
As I remember, most cases where people have recently been asking for
backend pid were related to temp tables because they were named by pid.
I don't think they are anymore. (?)
We can do two things. We can either rename it to pg_backend_pid and
move it to the statistics section in the docs, w
OK, time to get moving folks. Looks like the increase in the function
args to 32 and the NAMEDATALEN to 128 has been sufficiently tested. Tom
has some ideas on removing some memset() calls for function args to
speed things up, but we don't have to wait for that go get going. The
end of August
Also, let me add that CLUSTER in 7.3 will be fully functional because we
will no longer be changing the oid of the table during cluster. This
will allow people to use CLUSTER more frequently/safely.
---
Bruce Momjian wrot
Oleg Bartunov wrote:
> I just tried CLUSTER command at fts.postgresql.org to cluster
> fts index and got very visual performance win. Unfortunately
> I had to restore permissions and recreate other indices by hand.
> So, I'm interested what's a future of CLUSTER command ?
Yes, I have always liked
Hannu Krosing wrote:
> On Sat, 2002-08-03 at 23:20, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > How hard would it be to change pg_proc.proargtypes from oidvector to _oid
> >
> > Lack of btree index support for _oid would be the first hurdle.
>
> Is that index really neede
Christopher Kings-Lynne wrote:
> > The main area where it seems to get heavy use is during index builds,
> > and for 'CREATE TABLE AS SELECT...'.
> >
> > So I will remove the local buffer manager as part of the PITR patch,
> > unless there is further objection.
>
> Would someone mind filling me i
On Sat, 2002-08-03 at 23:20, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > How hard would it be to change pg_proc.proargtypes from oidvector to _oid
>
> Lack of btree index support for _oid would be the first hurdle.
Is that index really needed, or is it there just to enforce u
Tom Lane wrote:
> Did you happen to make any notes about the disk space occupied by the
> database? One thing I was worried about was the bloat that'd occur
> in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from
> costing disk space, this would indirectly slow things down due to
Oleg Bartunov dijo:
> On Sat, 3 Aug 2002, Alvaro Herrera wrote:
>
> > Oleg Bartunov dijo:
> >
> > > I just tried CLUSTER command at fts.postgresql.org to cluster
> > > fts index and got very visual performance win. Unfortunately
> > > I had to restore permissions and recreate other indices by h
On Sat, 3 Aug 2002, Alvaro Herrera wrote:
> Oleg Bartunov dijo:
>
> > I just tried CLUSTER command at fts.postgresql.org to cluster
> > fts index and got very visual performance win. Unfortunately
> > I had to restore permissions and recreate other indices by hand.
> > So, I'm interested what's a
I couldn't keep up with the list traffic this week, but I thought I saw
enough to convince me that after it was all said and done, I would still
be able to do `cvs co pgsql`. I'm finding today that after using cvsup
to sync up, I can no longer checkout pgsql, but pgsql-server instead. Is
this
Oleg Bartunov dijo:
> I just tried CLUSTER command at fts.postgresql.org to cluster
> fts index and got very visual performance win. Unfortunately
> I had to restore permissions and recreate other indices by hand.
> So, I'm interested what's a future of CLUSTER command ?
I'm working on CLUSTER.
Hannu Krosing <[EMAIL PROTECTED]> writes:
> How hard would it be to change pg_proc.proargtypes from oidvector to _oid
Lack of btree index support for _oid would be the first hurdle.
Even if we wanted to do that work, there'd be some serious breakage
of client queries because of the historical di
On Sat, 2002-08-03 at 18:41, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I ran a crude test as follows (using a PHP script on the same machine.
> > Nothing else going on at the same time):
>
> > do 100 times
> >select 2+2+2+2+2+2+ ... iterated 9901 times
>
> > The results w
Tom Lane wrote:
> Did you happen to make any notes about the disk space occupied by the
> database? One thing I was worried about was the bloat that'd occur
> in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from
> costing disk space, this would indirectly slow things down due to
> On Fri, 2002-08-02 at 22:39, [EMAIL PROTECTED] wrote:
>
>>On 29 Jul 2002 18:27:40 MDT, the world broke into rejoicing as
>>Stephen Deasey <[EMAIL PROTECTED]> said:
>>
>>>Curt Sampson wrote:
>>>
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a co
I just tried CLUSTER command at fts.postgresql.org to cluster
fts index and got very visual performance win. Unfortunately
I had to restore permissions and recreate other indices by hand.
So, I'm interested what's a future of CLUSTER command ?
Regards,
Oleg
___
Joe Conway <[EMAIL PROTECTED]> writes:
> I ran a crude test as follows (using a PHP script on the same machine.
> Nothing else going on at the same time):
> do 100 times
>select 2+2+2+2+2+2+ ... iterated 9901 times
> The results were as follows:
> INDEX_MAX_KEYS1632 64 128
Hannu Krosing <[EMAIL PROTECTED]> writes:
> You claimed that NOTIFY uses some _other_ backend id (i.e. not process
> id).
I did? Must have been momentary brain fade on my part. It's always
been process ID.
regards, tom lane
---(end of broadcast)
On Sat, 2002-08-03 at 16:32, Curt Sampson wrote:
> On 2 Aug 2002, Hannu Krosing wrote:
>
> > On Fri, 2002-08-02 at 12:15, Curt Sampson wrote:
> > > On 2 Aug 2002, Hannu Krosing wrote:
> > >
> > > > Could you brief me why do they discourage a syntactical frontent to a
> > > > feature that is trivi
On Fri, 2002-08-02 at 22:39, [EMAIL PROTECTED] wrote:
> On 29 Jul 2002 18:27:40 MDT, the world broke into rejoicing as
> Stephen Deasey <[EMAIL PROTECTED]> said:
> > Curt Sampson wrote:
> >> I'm still waiting to find out just what advantage table inheritance
> >> offers. I've asked a couple of ti
On Sat, 2002-08-03 at 01:25, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Perhaps a more relevant question is why are we cluttering the namespace
> > > with any such function at all? What's the use case for it?
>
> > It was requested because it is exposed in libpq and people
On Fri, 2 Aug 2002, Thomas Lockhart wrote:
> [Symlinks] don't scale,
Given that we have only one directory for the log file, this would not
appear to be a problem.
> they are not portable,
That's certainly a problem if we intend to run on systems without them.
> and it is difficult for
> appl
On 2 Aug 2002, Hannu Krosing wrote:
> On Fri, 2002-08-02 at 12:15, Curt Sampson wrote:
> > On 2 Aug 2002, Hannu Krosing wrote:
> >
> > > Could you brief me why do they discourage a syntactical frontent to a
> > > feature that is trivially implemented ?
> >
> > What's the point of adding it? It's
> The main area where it seems to get heavy use is during index builds,
> and for 'CREATE TABLE AS SELECT...'.
>
> So I will remove the local buffer manager as part of the PITR patch,
> unless there is further objection.
Would someone mind filling me in as to what the local bugger manager is and
> So I am still interested in PostgreSQL's ability to deal with
> multimillon records tables.
Postgres has no problem with multimillion row tables - many people on this
list run them - just don't do sequential scans on them if you can't afford
the time it takes.
Chris
60 matches
Mail list logo
