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
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
how
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 just one more
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
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 need it 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 couple of times here,
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 trivially implemented
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
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
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
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 times here, and
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 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 were as
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
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. I
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
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 future
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 hand.
So,
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 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
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 in as to
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 needed, or is it
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
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
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
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,
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
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)
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 shared
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 checks
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 rename it
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 scans.
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
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 have we
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 given
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 could speed
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. There
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 can do two
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 given
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 comparison to
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) we would
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 activity
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 :-(. I
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();
This
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
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 thought of
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
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. TABLE + ON
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):
eutm
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
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 - lowest
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 sense
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 think it
53 matches
Mail list logo
