Quoting daveg <[EMAIL PROTECTED]>:
On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote:
On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote:
> It would also be interesting if EXPLAIN could optionally be a
> function that returns a datum of type XML, to allow further
> proc
Tom Lane wrote:
The data structure I'd suggest is a simple array of pointers
to the underlying hash table entries. Since you have a predetermined
maximum number of lexemes to track, you can just palloc the array once
--- you don't need the expansibility properties of a list.
The number of lex
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Have you looked into the machine's kernel log to see if there is any
> evidence of low-level distress (hardware or filesystem level)? I'm
> wondering if ENOSPC is being reported because it is the closest
> available errno code, but the real problem is some
Dumb question:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
> What's the benefit of a multi-column GIN index over multiple
> single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb538 Mb
Speed: *1.885* ms4.9
On Thu, Jul 03, 2008 at 01:45:06AM -0400, Ken Camann wrote:
> When 32-bit arrived (much too late, at Microsoft) most x86 compilers
> that had formerly used the segmented memory model made int 4 bytes
> like people felt "it was supposed to be" but left long at 4 the way it
> was so as not to bloat a
Am Freitag, 4. Juli 2008 schrieb Tom Raney:
> Regarding the XML datum, in order to support that, will all users need
> to compile with libxml? Are there any lighter weight solutions to
> serialize other than libxml?
You can create XML without libxml.
--
Sent via pgsql-hackers mailing list (
On Fri, 4 Jul 2008, Teodor Sigaev wrote:
What's the benefit of a multi-column GIN index over multiple
single-column GIN indexes?
Page 12 from presentation on PgCon
(http://www.sigaev.ru/gin/fastinsert_and_multicolumn_GIN.pdf):
Multicolumn index vs. 2 single column indexes
Size:539 Mb
I just noticed that setting log_rotation_age to a value larger than 24
days results in rather weird output (I have not actually tested yet if
that affects the functionality too or just the output):
test=# show log_rotation_age;
log_rotation_age
--
-2134967296ms
(1 row)
this
On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
> --On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
>
> >>
> >> I'd like to implement them if we agree on them
> >
> > Bernd, have you made any progress on this?
>
> Here's a patch for this. I'll add it to
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> below this is going to convert \ to /, wouldn't it be clearer to
>>> describe the path prefix as Global/PostgreSQL: in the first place?
>
>> Eh, that shows another bug I think. It should *not* convert the \ in
>> "Global\", because
[EMAIL PROTECTED] ("Ken Camann") writes:
> On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Ken Camann" <[EMAIL PROTECTED]> writes:
>>> EMT64/AMD64 is new compared to the older architectures, I
>>> would guess the older ones predate the time when it became a somewhat
>>> de
Volkan YAZICI napsal(a):
Hi,
pg_dump is capable of dumping objects with respect to their dependency
relations. It'd be really awesome if pg_dump can also handle
parallelizing primary key, foreign key and index creation queries into
separate files. Would such a think be possible? Comments?
--On Freitag, Juli 04, 2008 11:31:07 +0200 Stefan Kaltenbrunner
<[EMAIL PROTECTED]> wrote:
I just noticed that setting log_rotation_age to a value larger than 24
days results in rather weird output (I have not actually tested yet if
that affects the functionality too or just the output):
test
I performed review of merged patch from Robert Treat. At first point the patch
does not work (SunOS 5.11 snv_86 sun4u sparc SUNW,Sun-Fire-V240)
truncate ... ok
alter_table ... FAILED (test process exited with exit code 2)
sequence ... ok
polym
Zdenek Kotala wrote:
> 1) Naming convention:
>
> - Some probes uses "*end", some "*done". It would be good to select one name.
> - I prefer to use clog instead of slru in probes name. clog is widely known.
But slru is also used in pg_subtrans and pg_multixact. Which maybe
says that we oughta h
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The data structure I'd suggest is a simple array of pointers
>> to the underlying hash table entries. Since you have a predetermined
>> maximum number of lexemes to track, you can just palloc the array once
>> --- you don't need
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 4. Juli 2008 schrieb Tom Raney:
>> Regarding the XML datum, in order to support that, will all users need
>> to compile with libxml? Are there any lighter weight solutions to
>> serialize other than libxml?
> You can create XML withou
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> What happens if someone launches version 8.3.3 postgres.exe and version
>> 8.3.4 postgres.exe at the same time, on the same data directory? Will
>> the interlock that prevents two postmasters from starting at the same
>> tim
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Autovacuum_start probe is alone. I propose following probes for completeness:
>>
>> proc-autovacuum-start
>> proc-autovacuum-stop
>> proc-bgwriter-start
>> proc-bgwriter-stop
> Separate proc-autovacuum-worker-start and proc-autovacuum-launcher-start,
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
1) Naming convention:
- Some probes uses "*end", some "*done". It would be good to select one name.
- I prefer to use clog instead of slru in probes name. clog is widely known.
But slru is also used in pg_subtrans and pg_multixact. Which mayb
Tom Lane napsal(a):
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Autovacuum_start probe is alone. I propose following probes for completeness:
proc-autovacuum-start
proc-autovacuum-stop
proc-bgwriter-start
proc-bgwriter-stop
Separate proc-autovacuum-worker-start and proc-autovacuum-launcher-st
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>>> proc-master-start
>>> proc-master-stop
>>
>> What's "master" here?
>
> Main process - postmaster.
Huh, surely we're not interested in tracking postmaster start?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Th
Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> I see no value in cluttering the system with useless probes. The worker
>> start/stop are the only ones here with any conceivable application IMHO.
>
> As I answered to Alvaro. I needed to catch start of backend several times
> to track call flow or
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
proc-master-start
proc-master-stop
What's "master" here?
Main process - postmaster.
Huh, surely we're not interested in tracking postmaster start?
It depends. See following schema example
postgres::proc-master-s
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
I see no value in cluttering the system with useless probes. The worker
start/stop are the only ones here with any conceivable application IMHO.
As I answered to Alvaro. I needed to catch start of backend several times
to tr
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas wrote:
>>> What happens if someone launches version 8.3.3 postgres.exe and version
>>> 8.3.4 postgres.exe at the same time, on the same data directory? Will
>>> the interlock that prevents two postmasters from start
Magnus Hagander wrote:
> Tom Lane wrote:
> > According to what you just told me, the original coding is storing the
> > name in a "local namespace", which presumably means it won't conflict
> > anyway. Ergo, the existing coding is simply broken and there's nothing
> > we can do about it.
>
> Loc
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The data structure I'd suggest is a simple array of pointers
to the underlying hash table entries. Since you have a predetermined
maximum number of lexemes to track, you can just palloc the array once
--- you don'
On Jul 3, 2008, at 09:53, Alvaro Herrera wrote:
Thanks. What would citext_hash() look like? I don't see a
text_hash() to
borrow from anywhere in src/.
See hash_any(). I assume the difficulty is making sure that
hash("FOO") = hash("foo") ...
Great, big help, thank you. So does this look se
On Jul 2, 2008, at 22:14, Tom Lane wrote:
The "leak" is irrelevant for larger/smaller. The only place where
it's
actually useful to do PG_FREE_IF_COPY is in a btree or hash index
support function. In other cases you can assume that you're being
called in a memory context that's too short-liv
Replying to myself, but I've made some local changes (see other
messages) and just wanted to follow up on some of my own comments.
On Jul 2, 2008, at 21:38, David E. Wheeler wrote:
4) Operator = citext_eq is not correct. See comment
http://doxygen.postgresql.org/varlena_8c.html#8621d064d14f
32 matches
Mail list logo
