Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Good, but the salient followup questions to that are (1) backed up to
>> where exactly?, and (2) how many days' past backups could we get at,
>> if we had to?
> They are dumped to a NFS share on this schedule. That NFS share is
> dum
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Good, but the salient followup questions to that are (1) backed up to
>>> where exactly?, and (2) how many days' past backups could we get at,
>>> if we had to?
>
>> They are dumped to a NFS share on this schedule
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Good, but the salient followup questions to that are (1) backed up to
> >> where exactly?, and (2) how many days' past backups could we get at,
> >> if we had to?
>
> > They are dumped to a NFS share on this sch
On 8/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > Kris Jurka <[EMAIL PROTECTED]> writes:
> >> It looks like parts of the CVS repository have been mistagged as belonging
> >> to REL7_4_STABLE or have been corrupted somehow:
> I have no idea how you make CVS do that, but I'm
> sure ther
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
>>> They are dumped to
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
I'd like someone to double-check that though. Also maybe we should back
up the repository first?
>>> Just for your info: all VMs on tribble, which includes cvs, are backed
>>> up a
Stefan Kaltenbrunner wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
> I'd like someone to double-check that though. Also maybe we should back
> up the repository first?
Just for your info: all VMs on tribble, whi
Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
> we should at least log such commands, and maybe disallow to anyone
> except Marc's "pgsql" account.
I don't think we should disallow it. Or otherwise we might one day be stuck
if we need to release while some specific person is on vacation.
On Wed, 2007-08-15 at 06:51 +0100, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > On Tue, 2007-08-14 at 16:27 -0500, Decibel! wrote:
> >> Isn't this what Grouped Index Tuples is?
> >
> > http://community.enterprisedb.com/git/git-readme.txt
> >
> > It looks like GIT is a little different.
> >
On Tue, 2007-08-14 at 12:29 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-08-14 at 12:09 -0400, Tom Lane wrote:
> >> heapam.c lines 1843-1852 presume previous xmax can be hinted
> >> immediately, ditto lines 2167-2176, ditto lines 2716-2725.
> >> I think probab
On Tue, 2007-08-14 at 17:41 -0400, Tom Lane wrote:
> I've just finished re-reading the prior thread, and here are what seem
> to me to be the salient points:
>
> * Oleg, Teodor, and all of the old-line users of tsearch2 are
> comfortable with setting up a trigger to maintain a materialized
> tsve
On Wed, 2007-08-15 at 08:10 +0200, Magnus Hagander wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> Since I don't think that a datatype solution is the way to go,
> >>> I don't feel that we are as far away from an agreement as Bruce
> >>> is worried
Magnus Hagander wrote:
> > But I would like a design that is bulletproof in dump/reload scenarios,
> > and I think it's fair to question that aspect of the tsearch2 design
> > because we've seen many reports of people having trouble updating
> > databases that use tsearch2.
>
> dump/reload is *the
On Wed, Aug 15, 2007 at 10:23:00AM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > But I would like a design that is bulletproof in dump/reload scenarios,
> > > and I think it's fair to question that aspect of the tsearch2 design
> > > because we've seen many reports of people having tro
I don't like the locking... take a look at Ex 37-1 at the end of
http://lnk.nu/postgresql.org/fhe.html for a better way (though, the
comment below about going into an infinite loop is a good observantion,
but I think perhaps after some number of fast tries it should start
putting a sleep in the loo
On Wed, Aug 15, 2007 at 06:47:05AM +0200, Pavel Stehule wrote:
> 2007/8/14, Decibel! <[EMAIL PROTECTED]>:
> > On Tue, Aug 14, 2007 at 05:38:33PM +0200, Pavel Stehule wrote:
> > > 2007/8/14, Bruce Momjian <[EMAIL PROTECTED]>:
> > > >
> > > > TODO item?
> > > >
> > > > + If your life is a hard driv
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> ISTM that the functional index would be considerably smaller than the
> additional column approach, since tsvectors can be quite long. That
> seems like a very desirable thing with larger textbases. However,
> without an additional column certain queries
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
They are dumped to a NFS share on this sche
I have added another idea for index-only scans to the TODO list:
> A third idea would be for a heap scan to check if all rows are visible
> and if so set a per-table flag which can be checked by index scans.
> Any change to the table would have to clear the flag. To detect
> changes durin
I was talking to someone at LinuxWorld and they mentioned they often
have activity of 6k SELECTs per second, and that they were needing to
autovacuum every few days because of xid wraparound.
I did some calculations and found that:
> 6000 * 60 * 60 * 24
51840
or 500 m
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>
>>> Tom Lane wrote:
>>>
Good, but the salient followup questions to that are (1) backed up to
where exactly?, and (2) how many days' past backups could we get at,
if we had to?
Peter Eisentraut wrote:
> Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
>> we should at least log such commands, and maybe disallow to anyone
>> except Marc's "pgsql" account.
>
> I don't think we should disallow it. Or otherwise we might one day be stuck
> if we need to release while som
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
>>> we should at least log such commands, and maybe disallow to anyone
>>> except Marc's "pgsql" account.
>>
>> I don't think we should disallow it. Or otherwise we m
2007/8/15, Decibel! <[EMAIL PROTECTED]>:
> On Wed, Aug 15, 2007 at 06:47:05AM +0200, Pavel Stehule wrote:
> > 2007/8/14, Decibel! <[EMAIL PROTECTED]>:
> > > On Tue, Aug 14, 2007 at 05:38:33PM +0200, Pavel Stehule wrote:
> > > > 2007/8/14, Bruce Momjian <[EMAIL PROTECTED]>:
> > > > >
> > > > > TODO
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford to
vacuum every coupl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is enlarging the xid field something we should consider for 8.4?
>
> No. We just got the tuple header down to 24 bytes, we are not going
> to give that back and then some.
>
> If you are processing 6K transactions per second, you ca
Bruce Momjian wrote:
> Is enlarging the xid field something we should consider for 8.4? Is the
> autovacuum I/O less then the extra I/O needed for an expanded xid fields
> on every row?
I doubt that's going to happen...
Maybe we can do something to reduce the xid consumption? For example,
reuse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
>> we should at least log such commands, and maybe disallow to anyone
>> except Marc's "pgsql" accou
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Maybe we can do something to reduce the xid consumption? For example,
> reuse xids for read-only queries.
Hmm, that's an idea.
More simply, just keep the current transaction open (resetting
everything but the XID) if we have made no changes by the
On 8/14/07, Chris Browne <[EMAIL PROTECTED]> wrote:
> I recently had a chat with someone who was pretty intimate with Adabas
> for a number of years who's in the process of figuring things out
> about PostgreSQL. We poked at bits of the respective implementations,
> seeing some similarities and di
On Wed, Aug 15, 2007 at 12:49:52PM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Maybe we can do something to reduce the xid consumption? For example,
> > reuse xids for read-only queries.
>
> Hmm, that's an idea.
>
> More simply, just keep the current transaction op
On Wed, 2007-08-15 at 06:51 +0100, Heikki Linnakangas wrote:
> What Chris is suggesting is basically a special case of GIT, where all
> the heap tuples represented by an index tuple have the same key. I was
> actually thinking of adding a flag to index tuples to indicate that
> special case in GIT.
Decibel! <[EMAIL PROTECTED]> writes:
> Aren't there potential issues with keeping the same XID if a transaction
> in the middle has modified data?
I don't see any, as long as you take a new snapshot.
> Something else to think about... any app that's doing that kind of
> transaction rate is likely
On 8/15/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I have added another idea for index-only scans to the TODO list:
>
> > A third idea would be for a heap scan to check if all rows are visible
> > and if so set a per-table flag which can be checked by index scans.
> > Any change to the ta
On Wednesday 15 August 2007 09:49:52 Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Maybe we can do something to reduce the xid consumption? For example,
> > reuse xids for read-only queries.
>
> Hmm, that's an idea.
>
> More simply, just keep the current transaction open (res
Bruce,
> I have added another idea for index-only scans to the TODO list:
> > A third idea would be for a heap scan to check if all rows are
> > visible and if so set a per-table flag which can be checked by index
> > scans. Any change to the table would have to clear the flag. To
> > detect ch
Heikki,
> Should we change the ordering of pg_settings?
Well, an unfixed issue in pg_settings is that the category/subcategory
relationship got represented by a non-atomic field which makes sorting on
that difficult.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I have added another idea for index-only scans to the TODO list:
>
>> A third idea would be for a heap scan to check if all rows are visible
>> and if so set a per-table flag which can be checked by index scans.
>> Any change to the table would h
Marc G. Fournier wrote:
>
>
> --On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
> <[EMAIL PROTECTED]> wrote:
>
>> Am Mittwoch, 15. August 2007 04:20 schrieb Tom Lane:
>>> we should at least log such commands, and maybe disallow to anyone
>>> except Marc's "pgsql" account.
>> I don
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Is enlarging the xid field something we should consider for 8.4?
>
> No. We just got the tuple header down to 24 bytes, we are not going
> to give that back and then some.
>
> If you are processing 6K transactions per second, you can
A hybrid scan approach combined with this idea would fit nicely - provide
results for tids that are directly visible and set a bit in a bitmap for those
that need recheck and extend recheck to take a bitmap (wait - it already does
:-)
- Luke
Msg is shrt cuz m on ma treo
-Original Message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, August 15, 2007 20:57:14 +0200 Magnus Hagander
<[EMAIL PROTECTED]> wrote:
> Marc G. Fournier wrote:
>>
>>
>> --On Wednesday, August 15, 2007 12:11:35 +0200 Peter Eisentraut
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Am Mittwoch, 15. Aug
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
regards, tom lane
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with "pgbench -c 150 -t 2 -s
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > I have added another idea for index-only scans to the TODO list:
> >
> >> A third idea would be for a heap scan to check if all rows are visible
> >> and if so set a per-table flag which can be checked by index scans.
> >
Marc G. Fournier wrote:
>> If you're doing that, we should probably just delete the pgsql userid
>> from the system? Or at least change it so it doesn't have 'dev'
>> permissions. That way you can't do it wrong in that direction ;-)
>> Seems reasonable?
>
> there is no pgsql user *on* cvs.postgres
Dawid Kuroczko wrote:
> Some time ago I've had an idea that it might be possible to compress
> th index size, even if it is a unique index. Take the path example.
> My idea would be to to split indexed value to 8-byte chunks.
> For example: /var/lib/postgresql/8.2/main would be split into:
> "/v
Heikki Linnakangas írta:
Zoltan Boszormenyi wrote:
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with "pgbench
Zoltan Boszormenyi wrote:
> Tom Lane írta:
>> It's hard to see how anyone could be doing 6K xacts/sec unless most are
>> read-only.
>
> In a recent stress test with our PostgreSQL-based cluster between two
> machines
> 3 million transaction were performed with "pgbench -c 150 -t 2 -s 200"
> in
Zoltan Boszormenyi wrote:
> >> used a real disk, the secondary used tmpfs as PGDATA. Say whatever you want
> >> about my disk lying about flush, its 75MB/sec transfer rate transfer
> >> rate is real.
> >> So 5 million "real" transaction in 24 hours is not unrealistic.
> >>
> >
> > 6k xacts / s
[EMAIL PROTECTED] ("Dawid Kuroczko") writes:
> On 8/14/07, Chris Browne <[EMAIL PROTECTED]> wrote:
>> I recently had a chat with someone who was pretty intimate with Adabas
>> for a number of years who's in the process of figuring things out
>> about PostgreSQL. We poked at bits of the respective
On Wednesday 15 August 2007 13:54, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > Aren't there potential issues with keeping the same XID if a transaction
> > in the middle has modified data?
>
> I don't see any, as long as you take a new snapshot.
>
I'm a little confused, wouldnt the
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> That general approach of storing a common part leading part just once is
> called prefix compression. Yeah, it helps a lot on long text fields.
> Tree structures like file paths in particular.
You kind of want to do avoid both the prefix and the
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm a little confused, wouldnt the transaction that waits 30 minutes before
> modifying data need to get an XID that jives with the system when it's
> transaction started, not when it began manipulating data?
Why?
> Would it really be safe to take a ne
Magnus Hagander wrote:
> I don't use the functional index part, but for new users I can see how
> that's certainly a *lot* easier.
Can someone with modern hardware test to see if it's
still quite a bit slower than the extra column. I had
tried it too years ago; and found the functional index
to
>>> On Wed, Aug 15, 2007 at 5:06 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> I'm a little confused, wouldnt the transaction that waits 30 minutes before
>> modifying data need to get an XID that jives with the system when
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> You wouldn't take a new snapshot. The thought that occurs to me is that
>> there's no reason that a transaction has to have an XID for itself
>> before it takes a snapshot. We always special-case our own XID any
On Aug 15, 2007, at 1:54 PM, Gregory Stark wrote:
A third idea would be for a heap scan to check if all rows are
visible
and if so set a per-table flag which can be checked by index
scans.
Any change to the table would have to clear the flag. To detect
changes during the heap scan a
Gregory Stark wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>
>> That general approach of storing a common part leading part just once is
>> called prefix compression. Yeah, it helps a lot on long text fields.
>> Tree structures like file paths in particular.
>
> You kind of want to d
58 matches
Mail list logo
