Guillaume Smet wrote:
On 9/19/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Can you run the same set of tests in a single byte encoding like latin1?
Here are the results (each query was executed several times before this result):
** 8.1 **
cityvox_latin1=# SELECT e.numeve FROM evene
On 9/19/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Can you run the same set of tests in a single byte encoding like latin1?
Here are the results (each query was executed several times before this result):
** 8.1 **
cityvox_latin1=# SELECT e.numeve FROM evenement e WHERE e.libgeseve
ILIKE '%h
Gregory Stark <[EMAIL PROTECTED]> writes:
> But given Tom's comments this commit stands out too:
> From: "Alvaro Herrera" <[EMAIL PROTECTED]>
> Log Message:
> ---
> Release the exclusive lock on the table early after truncating it in lazy
> vacuum, instead of waiting till commit.
I had th
On 9/19/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> It's at least good to see that the LIKE case has some useful speedup in
> 8.3.
It can be due to your patch or to the varlena header patch. Seqscan is
a bit faster too.
> Can you run the same set of tests in a single byte encoding like latin1
Pedro Belmino wrote:
> I am with a problem. When I am using debugger, breakpoints that they
> are inside of main function (stop the execution in the marked point)
> but when breakpoint is marked in another archive (index.c for
> example) breakpoint does not function (the execution in the point
> do
Looking back, by far the largest change in the period Sep 1 - Sep 11 was the
lazy xid calculation and read-only transactions. That seems like the most
likely culprit.
But given Tom's comments this commit stands out too:
--- Begin Message ---
Log Message:
---
Release the exclusive lock
On Tue, 2007-09-18 at 19:13 -0400, Tom Lane wrote:
> Radoslaw Zielinski <[EMAIL PROTECTED]> writes:
> > "pg_ctl -w -D ... start" doesn't work when unix_socket_directory is set
> > to somewhere else than the compiled in default ("/tmp").
>
> pg_ctl not working is going to be the very least of your
Hello,
I am with a problem. When I am using debugger, breakpoints that they are
inside of main function (stop the execution in the marked point) but when
breakpoint is marked in another archive (index.c for example) breakpoint
does not function (the execution in the point does not stop), because th
Guillaume Smet wrote:
Andrew, All,
On 5/22/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But before I commit this I'd appreciate seeing some more testing, both
for correctness and performance.
I finally found some time to test this patch on our data. As our
production databa
Gregory Stark wrote:
> Is there still time to slip this into the upcoming 8.2.5?
8.2.5 is no longer upcoming.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Gregory Stark wrote:
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
pgbfprod=# select sysname, stage, snapshot from build_status where log ~
$$read only \d+ of \d+ bytes$$;
sysname |stage | snapshot
---+--+--
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>
>> pgbfprod=# select sysname, stage, snapshot from build_status where log ~
>> $$read only \d+ of \d+ bytes$$;
>> sysname |stage | snapshot
>> ---+--+-
>> zebra
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> pgbfprod=# select sysname, stage, snapshot from build_status where log ~
> $$read only \d+ of \d+ bytes$$;
> sysname |stage | snapshot
> ---+--+-
> zebra | InstallCheck | 2007-09-11 1
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
> Just for information. Venezuela is going to have new timezone change
> (30minutes
> shift) on this weekend. This change is not yet integrated in the last version
> in Olson database. (Original announcement said it happens on 1.1.2008)
Is there still
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of
8192 bytes
Is that repeatable? What sort of filesystem are
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>
>>> Tom Lane wrote:
>>>
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ! ERROR: could not read block 2 of relation 1663/16384/2606: read
> only 0 of 8192 bytes
>>>
On Sep 19, 2007, at 2:08 AM, Guillaume Smet wrote:
On 9/19/07, Decibel! <[EMAIL PROTECTED]> wrote:
Odd... I'd expect it to actually be beneficial to run analyze on a
table
at roughly the same time as PK building, because you'd make better
use
of cache.
Sure if your database fits entirely i
On Sep 19, 2007, at 8:08 AM, Tom Lane wrote:
Decibel! <[EMAIL PROTECTED]> writes:
3 isn't that important to me, but 4 is:
4. Doesn't hammer the database to measure
And pgstattuple fails #4 miserably. Want to know the average dead
space
in a 500GB database? Yeah, right
So we could put
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of
8192 bytes
Is that repeatable? What sort of filesystem are you testing on?
(soft-mou
Andrew, All,
> On 5/22/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > But before I commit this I'd appreciate seeing some more testing, both
> > for correctness and performance.
I finally found some time to test this patch on our data. As our
production database is still using 8.1, I made my t
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> ! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0
>>> of 8192 bytes
>>
>> Is that repeatable? What sort of filesystem are you testing on?
>> (soft-mo
Simon Riggs <[EMAIL PROTECTED]> writes:
> We're able to dynamically add AMs in the way you suggest, but there is
> no way to alter the RMgrTable to either add a new RM or re-assign one of
> the unused RMs.
Hmmm...
> 1. Remove the "Const" in front of RmgrTable in rmgr.c. That would allow
> re-assi
Decibel! <[EMAIL PROTECTED]> writes:
> 3 isn't that important to me, but 4 is:
> 4. Doesn't hammer the database to measure
> And pgstattuple fails #4 miserably. Want to know the average dead space
> in a 500GB database? Yeah, right
So we could put a vacuum_cost_delay() in it ...
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> There is one wacky idea I haven't dared to propose yet:
>
> We could lift the limitation that you can't defragment a page that's
> pinned, if we play some smoke and mirrors in the buffer manager. When
> you prune a page, make a *copy* of the page
On 19/09/2007, Tom Lane <[EMAIL PROTECTED]> wrote:
> Radoslaw Zielinski <[EMAIL PROTECTED]> writes:
> > "pg_ctl -w -D ... start" doesn't work when unix_socket_directory is set
> > to somewhere else than the compiled in default ("/tmp").
> pg_ctl not working is going to be the very least of your wor
On 19/09/2007, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Radoslaw Zielinski wrote:
[...]
> > That would be fine for a particular installation, but isn't really
> > suitable for a startup script shipped with a linux distribution. Sure,
[...]
> I think it's broken for a distro to ship with config
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> We could lift the limitation that you can't defragment a page that's
>> pinned, if we play some smoke and mirrors in the buffer manager. When
>> you prune a page, make a *copy* of the page you're pruning, and keep
>> both versions
On 9/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> In your last post you mentioned multiple UPDATEs. Pruning multiple times
> for successive UPDATEs isn't going to release more space, so why do it?
>
>
I guess the point is when you do the first update, there is enough free
space
in the page a
Decibel! wrote:
> On Tue, Sep 18, 2007 at 11:32:52AM -0400, Tom Lane wrote:
>>> Another option would be to prune whenever the free space goes
>>> below table fillfactor and hope that users would set fillfactor so that
>>> atleast one updated tuple can fit in the block. I know its not best to
>>> re
On Tue, 2007-09-18 at 12:10 -0400, Tom Lane wrote:
> I wrote:
> > * The patch makes undocumented changes that cause autovacuum's decisions
> > to be driven by total estimated dead space rather than total number of
> > dead tuples. Do we like this?
>
> No one seems to have picked up on this point,
On Tue, 2007-08-07 at 17:03 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > How hard will it be to add the infrastructure to allow new index types
> > to be added to the server dynamically?
>
> INSERT INTO pg_am VALUES (...);
>
> I don't really think we need more than that,
On 9/19/07, Decibel! <[EMAIL PROTECTED]> wrote:
> Odd... I'd expect it to actually be beneficial to run analyze on a table
> at roughly the same time as PK building, because you'd make better use
> of cache.
Sure if your database fits entirely in RAM (otherwise if two big
tables are analyzed while
32 matches
Mail list logo
