Hi folks,
As I said on -PATCHES, I've been working on an utility to get
a b-tree index information. I'm happy to introduce
my new functions to you.
pgstattuple module provides a `pgstatindex()`, and other small
functions, which allow you to get b-tree internal information.
I believe this module
Tom Lane wrote:
If that actually worked, it'd be one thing, but it doesn't work and
isn't going to do so in 8.2. So I think people will indeed be trying
to use setting || unit for display purposes. In any case 8kB isn't
a valid unit.
I thought we set SHOW ALL aside for display purposes and
Am Donnerstag, den 27.07.2006, 08:30 -0400 schrieb Tom Lane:
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
On 7/15/06, Tom Lane [EMAIL PROTECTED] wrote:
Anyway, Qingqing's question still needs to be answered: how can a sort
of under 30k items take so long?
It happens because (as previously suggested by Tom) the dataset for
the 'short' (~10k rows, .3 sec) sort has no rows whose leftmost fields
Ühel kenal päeval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
I don't see how this gives us ability to vacuum more rows, as the
snapshot of a serializable
Hello,
I miss better support OUT arguments in plerlu:
create or replace function foo(out p varchar[]) as $$ return { p = [pavel,
jana] }; $$ language plperlu;
postgres=# select foo();
ERROR: array value must start with { or dimension information
postgres=#
I starting work on it. I hope It
Hi hackers,
I tackled the performance problem on SUBTRANS module with Okano.
He and I reach a conclusion that SubTrans log is heavily read on a specific
access pattern in my TPC-W implementation. There seems to be awful traffic
on SUBTRANS to check visivility of tuples in
Ühel kenal päeval, N, 2006-07-27 kell 01:03, kirjutas Tom Lane:
Michael Glaesemann [EMAIL PROTECTED] writes:
I've seen this mentioned a couple of times. I'm not nearly as
familiar with these settings as I should be, but it seems to me that
if the memory size *does* need to be a integral
Can one of the Windows buildfarm owners please try building and running
make check by hand rather than using the buildfarm script? It looks
like they all stopped reporting around the same time, and this might
give us a better clue about when things fall over.
Also, if you're up for it,
Andrew Dunstan wrote:
Can one of the Windows buildfarm owners please try building and running
make check by hand rather than using the buildfarm script? It looks
like they all stopped reporting around the same time, and this might
give us a better clue about when things fall over.
Also,
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
Can one of the Windows buildfarm owners please try building and running
make check by hand rather than using the buildfarm script? It looks
like they all stopped reporting around the same time, and this might
give us a better clue about
I really like the CREATE INDEX CONCURRENTLY suggestion that I've seem in this
thread. That seems like a good alternative to ONLINE and is very easy to
understand.
Regards,
Paul
--
View this message in context:
The TimeZone changes are looking might suspicious ...
cheers
andrew
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
Can one of the Windows buildfarm owners please try building and running
make check by hand rather than using the buildfarm script? It looks
like they all stopped
Charles Duffy [EMAIL PROTECTED] writes:
... For the 'long' data, the compare moves on rightward until it
encounters 'flato', which is a TEXT column with an average length of
7.5k characters (with some rows up to 400k). The first 6 columns are
mostly INTEGER, so compares on them are relatively
I thought these new functions were going to be merged into
/contrib/pgstattuple.
---
satoshi nagayasu wrote:
Hi folks,
As I said on -PATCHES, I've been working on an utility to get
a b-tree index information. I'm happy
Bruce Momjian [EMAIL PROTECTED] writes:
Good question. Imagine you have a serializable transaction like
pg_dump, and then you have lots of newer transactions. If pg_dump is
xid=12, and all the new transactions start at xid=30, any row created
and expired between 12 and 30 can be removed
Hannu Krosing wrote:
?hel kenal p?eval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
I don't see how this gives us ability to vacuum more rows, as the
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The TimeZone changes are looking might suspicious ...
FATAL: failed to initialize timezone_abbreviations to Default
Hm. It looks like this is working in the postmaster but failing
in subprocesses. I'll see if I can duplicate it using
I wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
Just to confirm, it does look like there's a discrepancy between what
is in the documentation and the actual behavior of the server. The
documentation indicates that SJIS is a valid server encoding:
This is a documentation error ---
Hi All,
I am facing problem while using CVS. I am working on Solaris 10 and
trying to fetch source code of Postgres as Anonymous CVS as follows
:
/$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login /
(url : http://developer.postgresql.org/docs/postgres/anoncvs.html
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Good question. Imagine you have a serializable transaction like
pg_dump, and then you have lots of newer transactions. If pg_dump is
xid=12, and all the new transactions start at xid=30, any row created
and expired between 12 and
Andrew Dunstan [EMAIL PROTECTED] writes:
The TimeZone changes are looking might suspicious ...
FATAL: failed to initialize timezone_abbreviations to Default
Hm. It looks like this is working in the postmaster but failing
in subprocesses. I'll see if I can duplicate it using EXEC_BACKEND.
There are some days where High Speed Internet for Personal use just should
never have been invented ...
Over the past 24 hours, we've been experiencing a problem with the network
that has taken us a bit to identify as being at our end, and a little bit
longer to identify as being with the
Marc G. Fournier [EMAIL PROTECTED] writes:
The attacking IP, from the logs, appears to be 87.230.6.96 ...
Perhaps a complaint to their ISP is in order --- RIPE suggests
[EMAIL PROTECTED]
regards, tom lane
---(end of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why?
Because it's used to determine the Xmin that our vacuum will use. If
there is a transaction whose Xmin calculation included the Xid of a
transaction running vacuum, we have gained nothing from directly
On Fri, 2006-07-28 at 17:37, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
The attacking IP, from the logs, appears to be 87.230.6.96 ...
Perhaps a complaint to their ISP is in order --- RIPE suggests
[EMAIL PROTECTED]
That looks 1 level too high, the immediate source seems to
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why?
Because it's used to determine the Xmin that our vacuum will use. If
there is a transaction whose Xmin calculation included the Xid of a
transaction running vacuum, we have gained nothing from directly
excluding said
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
But the patch changes things so that *everyone* excludes the vacuum from
their xmin. Or at least I thought that was the plan.
We shouldn't do that, because that Xmin is also used to truncate
SUBTRANS.
Yeah, but you were going to
On Jul 29, 2006, at 0:20 , Tom Lane wrote:
I'm going to change that text,
and also add a column to table 21-1 marking the supported server
encodings.
Thanks, Tom.
Michael Glaesemann
grzm seespotcode net
---(end of broadcast)---
TIP 1: if
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that actually worked, it'd be one thing, but it doesn't work and
isn't going to do so in 8.2. So I think people will indeed be trying
to use setting || unit for display purposes. In any case 8kB isn't
a valid unit.
I thought we
Michael Glaesemann [EMAIL PROTECTED] writes:
Just to confirm, it does look like there's a discrepancy between what
is in the documentation and the actual behavior of the server. The
documentation indicates that SJIS is a valid server encoding:
This is a documentation error --- SJIS is
On Fri, 28 Jul 2006 17:51:11 +0200
Csaba Nagy [EMAIL PROTECTED] wrote:
Perhaps a complaint to their ISP is in order --- RIPE suggests
[EMAIL PROTECTED]
That looks 1 level too high, the immediate source seems to be
http://www.ehost.pl/onas.php
I would go to both. ehost.pl could very well
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET ROLE dataentry;. However, I need
CURRENT_USER
On Fri, Jul 28, 2006 at 01:03:00AM +0200, Peter Eisentraut wrote:
Accepting page (or block?) as a unit might be a reasonable
You hit on something that's always irked me a bit... we tend to toss out
'page' and 'block' (and sometimes even 'buffer') randomly when referring
to different things that
* Clark C. Evans ([EMAIL PROTECTED]) wrote:
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET
On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
Jim Nasby wrote:
On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
What would be the use-case for hash indexes ? And what should be
done to make them faster than btree ?
If we knew,
On Thu, Jul 27, 2006 at 09:13:21AM -0700, Jie Zhang wrote:
On 7/26/06 11:50 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jie Zhang [EMAIL PROTECTED] writes:
On 7/26/06 10:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
... A nonuniform distribution would probably mean that some
of the bitmaps compress
I have email'd both, thanks ...
On Fri, 28 Jul 2006, Csaba Nagy wrote:
On Fri, 2006-07-28 at 17:37, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
The attacking IP, from the logs, appears to be 87.230.6.96 ...
Perhaps a complaint to their ISP is in order --- RIPE suggests
Bruce Momjian wrote:
I thought these new functions were going to be merged into
/contrib/pgstattuple.
Well, that's exactly what this patch seems to do ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote:
Bruce Momjian wrote:
I thought these new functions were going to be merged into
/contrib/pgstattuple.
Well, that's exactly what this patch seems to do ...
Well, looking at the tarball it puts everything in pgstatindex, and the
Makefile is:
On Thu, Jul 27, 2006 at 05:24:35PM -0400, Greg Stark wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Even if we stopped right there it would still be a huge win in many (most?)
cases. How often do the indexes on a table comprise even 50% of the table's
size?
I would say they're usually
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
The other POV is that we don't really care about long-running
transaction in other databases unless they are lazy vacuum, a case which
is appropiately covered by the patch as it currently stands. This seems
to be the POV that
I wrote:
There is room to argue that the numeric-arithmetic version would be
worth having on the grounds of greater precision or range, but it's a
big chunk of code and the public demand for the functionality has not
exactly been overwhelming.
Comments?
Since no one's even bothered to
TODO has an entry
o Allow UPDATE to handle complex aggregates [update]?
which I think is now obsolete, because we've settled on rejecting
aggregates at the top level of UPDATE, as the spec tells us to do.
Also, there's one remaining unfinished feature in the multi-argument
aggregate
Thanks, done.
---
Tom Lane wrote:
TODO has an entry
o Allow UPDATE to handle complex aggregates [update]?
which I think is now obsolete, because we've settled on rejecting
aggregates at the top level of
Clark C. Evans [EMAIL PROTECTED] writes:
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to shed privleges by SET
[EMAIL PROTECTED] (Jim C. Nasby) writes:
There are other transactions to consider: user transactions that will
run a long time, but only hit a limited number of relations. These are
as big a problem in an OLTP environment as vacuum is.
Rather than coming up with machinery that will
Jim C. Nasby wrote:
What I'm getting at is that I've never seen any explanation for the
theoretical use cases where a hash index would outperform a btree. If we
knew what kind of problems hash indexes were supposed to solve, we could
try and interest people who are solving those kinds of
Jim,
On 7/28/06 10:17 AM, Jim C. Nasby [EMAIL PROTECTED] wrote:
If the usefulness of bitmap indexes is still in doubt, could someone at
Greenplum provide data from actual data warehouses from actual
customers?
First, is anyone in doubt?
- Luke
---(end of
Luke Lonergan wrote:
Jim,
On 7/28/06 10:17 AM, Jim C. Nasby [EMAIL PROTECTED] wrote:
If the usefulness of bitmap indexes is still in doubt, could someone at
Greenplum provide data from actual data warehouses from actual
customers?
First, is anyone in doubt?
Sure. I think we are
Alvaro Herrera [EMAIL PROTECTED] writes:
The btree index needs to descend potentially many pages before getting
to the leaf page, where the actual index is stored. The hash index can
get at the leaf node in --supposedly-- one fetch. Btree is O(logN) to
get a single key, while hash is O(1).
On Fri, Jul 28, 2006 at 03:14:33PM -0400, Alvaro Herrera wrote:
Jim C. Nasby wrote:
What I'm getting at is that I've never seen any explanation for the
theoretical use cases where a hash index would outperform a btree. If we
knew what kind of problems hash indexes were supposed to solve,
Tom Lane wrote:
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The TimeZone changes are looking might suspicious ...
FATAL: failed to initialize timezone_abbreviations to Default
Hm. It looks like this is working in the postmaster but failing
in subprocesses. I'll see if I can
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I get a much more useful:
WARNING: could not read time zone file Default: No such file or directory
FATAL: failed to initialize timezone_abbreviations to Default
Hm, but why would the file not be there? Try hacking it to print the
whole path
On Thu, Jul 27, 2006 at 09:37:22PM -0400, Stephen Frost wrote:
Got any others beyond 'lastval'? Is 'lastval' even doing what you're
claiming (looking at the actual catalog on disk by using the OID)? My
recollection was that it was actually just storing the value in a bit of
backend-local
Bruce Momjian [EMAIL PROTECTED] writes:
I checked on MinGW and system() just returns the value returned by the
application. There isn't any special two-values-in-one layering like is
done on Unix for wait() and the return value from system(). It seems if
the child dies from a signal, the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I checked on MinGW and system() just returns the value returned by the
application. There isn't any special two-values-in-one layering like is
done on Unix for wait() and the return value from system(). It seems if
the child dies
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I checked on MinGW and system() just returns the value returned by the
application. There isn't any special two-values-in-one layering like is
done on Unix for wait() and the return value from system(). It
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Luke Lonergan
Sent: Friday, July 28, 2006 12:18 PM
To: Jim C. Nasby; Jie Zhang
Cc: Tom Lane; Mark Kirkwood; Josh Berkus; Gavin Sherry; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS]
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The cases that I think we most need to defend against are
(A) diff program not found
In summary, on MinGW, files differ or 'diff' not found, returns 1. If
one of the files to be compared does not exist, it returns 2. And of
course,
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I get a much more useful:
WARNING: could not read time zone file Default: No such file or directory
FATAL: failed to initialize timezone_abbreviations to Default
Hm, but why would the file not be there? Try hacking it to
Dann Corbit [EMAIL PROTECTED] writes:
Others have looked into the usefulness of bitmap indexes. Here is what
they found:
http://www.oracle.com/technology/pub/articles/sharma_indexes.html
I like this guy's style of argument: he admits a bitmap index on a
unique column will be much bigger than
What we don't want to happen is for us to release bitmapped indexes, and
find out later that btree is better in all cases. Then we have to tell
people not to use bitmapped indexes until we fix it in the next major
releasse. FYI, that is basically where we are right now with hash
indexes.
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
WARNING: could not read time zone file
/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No
such file or directory
$ ls -l /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default
-rw-r--r--1 pgbuild Administ
Stefan Kaltenbrunner wrote:
WARNING: could not read time zone file
/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No
such file or directory
This is an MSys virtual path, of which postgres naturally knows
nothing.We should have made the appropriate calls to turn it into
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
WARNING: could not read time zone file
/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No
such file or directory
so it's there but as a msys-virtual path - is that get passed to some
win32 function expecting a windows-style
On Fri, Jul 28, 2006 at 09:54:38PM +0200, Martijn van Oosterhout wrote:
Not the least of which is that arguments involving people can install
C code into the backend and break security are truisms: installed C
code can do *anything* which is why only superusers can install such
functions...
Phil Frost wrote:
Again, fix is really simple. Document the issue, making it damn clear in
the docs that the schema usage check means *nothing* when accessing an
object by OID, and advising users that the ways to access things by OID
are obscure but present and changing, so relying on the
Now that we've isolated the reason why regression tests are failing on
the Windows buildfarm members, it seems to me that there's a systemic
problem as well as the immediate bug. The problem is that guc.c is
doing an elog(ERROR) during InitializeGucOptions in postmaster children,
which ends up
On Fri, Jul 28, 2006 at 04:42:11PM -0400, Phil Frost wrote:
Again, fix is really simple. Document the issue, making it damn clear in
the docs that the schema usage check means *nothing* when accessing an
object by OID, and advising users that the ways to access things by OID
are obscure but
On 7/27/06, Darcy Buskermolen [EMAIL PROTECTED] wrote:
In one of those 3am lightbulbs I belive I have a way to make use of the 64-bit
XID counter and still maintain the ability to have backwards compatibility.
Is there any chance you could break this patch up into the 2 separate
componenets that
Bruce,
On 7/28/06 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
What we don't want to happen is for us to release bitmapped indexes, and
find out later that btree is better in all cases. Then we have to tell
people not to use bitmapped indexes until we fix it in the next major
releasse.
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
The other POV is that we don't really care about long-running
transaction in other databases unless they are lazy vacuum, a case which
is appropiately
/usr/sbin/dtrace -G -s utils/probes.d access/SUBSYS.o bootstrap/SUBSYS.o
catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
Tom Lane wrote:
Both of these pages say up front that they are considering read-only
data. So one of the questions that has to be answered (and the
submitters have been entirely mum about) is exactly how bad is the
update performance? If it's really awful that's going to constrain
the use
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
There are other transactions to consider: user transactions that will
run a long time, but only hit a limited number of relations. These
are
as big a problem in an OLTP
Ühel kenal päeval, R, 2006-07-28 kell 16:18, kirjutas Tom Lane:
Dann Corbit [EMAIL PROTECTED] writes:
Others have looked into the usefulness of bitmap indexes. Here is what
they found:
http://www.oracle.com/technology/pub/articles/sharma_indexes.html
I like this guy's style of argument:
Ühel kenal päeval, R, 2006-07-28 kell 16:25, kirjutas Bruce Momjian:
What we don't want to happen is for us to release bitmapped indexes, and
find out later that btree is better in all cases.
Actually I'd love it if adding bitmap indexes to core pg would magically
make btree several times
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Hi,
I have a query i am having trouble to formulate:
I used to do:
SELECT DISTINCT a0,a1 FROM public.t1
However, now i need to add the CTID attribute, but CTID is unique
thus, distinct is useless. In addition, i can't seem to be able to use max()
etc... or casting to anything on CTID in order to
Peter Eisentraut [EMAIL PROTECTED] writes:
Does it not like static functions?
I seem to recall Robert mentioning that they'd only recently fixed
DTrace to cope with probes in static functions. Maybe you need to
get an update?
regards, tom lane
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
WARNING: could not read time zone file
/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No
such file or directory
so it's there but as a msys-virtual path - is that get passed to some
win32 function
Jim Nasby wrote:
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
So instead of actually *solving* one problem you suggest *thinking*
about solving the general case ?
We have been *thinking* about dead-space-map for at least three
years by now.
No, I just wanted anyone who was actually
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
But the patch changes things so that *everyone* excludes the vacuum from
their xmin. Or at least I thought that was the plan.
We shouldn't do that, because that Xmin is also used to truncate
SUBTRANS.
Yeah,
Andrew Dunstan [EMAIL PROTECTED] writes:
Is there a reason we have to do things in this order? Could we just
postpone the call to InitializeGUCOptions() for a couple of lines?
Maybe, but I'm disinclined to mess with that. I have a patch that
makes it work like TimeZone, but am having
Is anyone working on this?
---
Tom Lane wrote:
korry [EMAIL PROTECTED] writes:
The problem is that, each time you go through
pgwin32_waitforsinglesocket(), you tie the *same* kernel object
(waitevent is static) to
On Fri, Jul 28, 2006 at 02:43:23PM -0700, Luke Lonergan wrote:
On 7/28/06 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
What we don't want to happen is for us to release bitmapped indexes, and
find out later that btree is better in all cases. Then we have to tell
people not to use
Mark,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 9:26 PM
But irrefutable? Irrefutable is not true. :-)
How about unrefuted. The evidence has not been refuted, and not
directly discussed or discounted.
BTREE can not be
88 matches
Mail list logo