Le 30/06/2010 06:53, Guillaume Lelarge a écrit :
Le 30/06/2010 05:25, Tom Lane a écrit :
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see the
On Wed, Jun 30, 2010 at 12:37 PM, Robert Haas robertmh...@gmail.com wrote:
One thought that occurred to me is that if the master and standby were
more tightly coupled, you could recover after a crash by making the
one with the further-advanced WAL position the master, and the other
one the
Using as a starting point the old bitmap patch in:
http://archives.postgresql.org/message-id/20081101000154.go27...@fune
I re-applied and re-worked the patch to see what kind of improvements over
btrees bitmaps actually provided.
Using a 20M rows table of 10/100/1000 random values, I've found
Leonardo F wrote:
Using as a starting point the old bitmap patch in:
http://archives.postgresql.org/message-id/20081101000154.go27...@fune
I re-applied and re-worked the patch to see what kind of improvements over
btrees bitmaps actually provided.
Using a 20M rows table of 10/100/1000
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see the patch on the commit-fest page yet.
Finally, I added it
While looking at Guillaume Lelarge's patch to add
CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
have a $SUBJECT.
Trivial patch attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
remove-stray-copydir.patch
Description: Binary
Robert Haas robertmh...@gmail.com writes:
While looking at Guillaume Lelarge's patch to add
CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
have a $SUBJECT.
Trivial patch attached.
The rmtree() declaration below it shouldn't be there either ...
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
While looking at Guillaume Lelarge's patch to add
CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
have a $SUBJECT.
Trivial patch attached.
The rmtree() declaration below it shouldn't be there either ...
On Thu, Jul 1, 2010 at 9:23 AM, Leonardo F m_li...@yahoo.it wrote:
Using as a starting point the old bitmap patch in:
http://archives.postgresql.org/message-id/20081101000154.go27...@fune
I re-applied and re-worked the patch to see what kind of improvements over
btrees bitmaps actually
Robert Haas robertmh...@gmail.com writes:
Hmm... no performance improvement? That's not encouraging.
The index being smaller ought to by itself provide some performance
improvement if, say, the smaller index can fit in cache and the larger
one can't. With a 6-15x size difference, that's
On Thu, Jul 1, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In particular, I recall some discussions about developing a streaming
API whereby an index AM could return a bitmap page-by-page or so,
rather than having to construct the whole thing in-memory before
anything could happen.
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something we want fixed for 9.0, as indicated by
Currently REASSIGN OWNED complains unexpected classid for operator
class and family.
For example,
create two users, user1 and user2
under user1:
create type oxetype as enum ('oxe1');
create operator class oxeops
default for type oxetype using btree as
function 1 array_lower(anyarray,integer);
Le 01/07/2010 17:54, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something
With logging_collector enabled, all the postgres log files are created with
mode 0600. This makes life complicated if users other than postgres need
to be able to examine the log files as well. Common example of this is when the
database runs under postgres user and DBA-s have named accounts. In
Martin Pihlak wrote:
Attached is a patch that adds a GUC log_file_mode which allows to specify
the creation mode for the log files. Presently it lacks documentation, which
I'll add if the idea is generally acceptable.
Now it really is attached.
regards,
Martin
***
Quoting Mike Fowler m...@mlfowler.com:
Should the IS DOCUMENT predicate support this? At the moment you get
the following:
template1=# SELECT
'townstownBidford-on-Avon/towntownCwmbran/towntownBristol/town/towns'
IS
DOCUMENT;
?column?
--
t
(1 row)
template1=# SELECT
In
principle a bitmap index scan should be significantly faster if the
index can
return the bitmap more or less natively rather than having
to construct
it.
The problem I'm seeing is that even on a 20M rows table, doing a
select * from t where c1=10 and c2=1
where c1 and c2 are low
Martin Pihlak martin.pih...@gmail.com writes:
It'd be convenient if the log files would have group read access. Then we
could
make all the DBA or monitoring users members of the postgres group and they'd
have direct access to the logs. However, as the group read is not likely a
universally
Tom Lane t...@sss.pgh.pa.us wrote:
Martin Pihlak martin.pih...@gmail.com writes:
It'd be convenient if the log files would have group read access.
Then we could make all the DBA or monitoring users members of the
postgres group and they'd have direct access to the logs.
However, as the group
Tom Lane wrote:
It doesn't appear to me that this helps unless you are willing to make
the containing director(ies) group-readable/executable as well, which is
something we've resisted doing.
The log can be moved outside of data directory by setting log_directory
to an absolute path. Then
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Martin Pihlak martin.pih...@gmail.com writes:
It'd be convenient if the log files would have group read access. Then we
could
make all the DBA or monitoring users members of the postgres group and
they'd
have direct access to the logs. However,
Martin Pihlak martin.pih...@gmail.com writes:
Tom Lane wrote:
It doesn't appear to me that this helps unless you are willing to make
the containing director(ies) group-readable/executable as well, which is
something we've resisted doing.
The log can be moved outside of data directory by
On 07/01/2010 12:56 PM, Kevin Grittner wrote:
I just tried creating a symbolic link to the pg_log directory and
flagging the existing logs within it to 640. As a member of the
group I was able to list and view the contents of log files through
the symbolic link, even though I didn't have any
On Thu, Jul 1, 2010 at 12:19 PM, Michael Tharp
g...@partiallystapled.com wrote:
That said, as Martin mentions one can easily place the log directory outside
of the data directory and set appropriate directory permissions.
If I can offer my $0.02, I recently solved such a problem on SuSE
Linux
On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 01/07/2010 17:54, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Tue, Jun 29,
Hello
I actualised plpgsql tutorial on address
http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#Design_of_triggers_in_PL.2FpgSQL
I hope so this document can be useful for people who start with plpgsql.
Sorry - my English is good for reading mailing list and coding in C
lang. Can some native
Le 01/07/2010 22:13, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 01/07/2010 17:54, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
On Thu, Jul 1, 2010 at 12:25 PM, Mike Fowler m...@mlfowler.com wrote:
Quoting Mike Fowler m...@mlfowler.com:
Should the IS DOCUMENT predicate support this? At the moment you get
the following:
template1=# SELECT
'townstownBidford-on-Avon/towntownCwmbran/towntownBristol/town/towns'
IS
hello:
I have good news for you. Last week ,I have Order china New Apple
iPad Wi-Fi 32GB
this website: www.Toradeo.com
I have received the product!
I believe you will find what you want there and have an good experience
on shopping from them.
Regards!
--
Sent via pgsql-hackers mailing list
Leonardo F wrote:
I'm trying to find more docs that explain the improvements of
bitmap indexes in other products... but most of what I've found
talks about bitmapAND/OR which is something that is very
cool, but that postgres already does even with btree indexes...
or index creation
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The attached patch shows the hint only during recovery.
BTW, it would be easier and more consistent with the rest of the code to
look at InRecovery, instead of messing around with the function
signature.
Fujii Masao wrote:
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
The fact that failover current does *not* terminate existing queries and
transactions was regarded as a feature by the audience, rather than a
bug, when I did demos
Bruce Momjian br...@momjian.us writes:
Fujii Masao wrote:
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
My feeling about it is that if you want fast failover you should not
have your failover target server configured as hot standby at all, let
alone hot standby with a
34 matches
Mail list logo
