Hi,
On Fri, Dec 5, 2008 at 7:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-12-05 at 12:09 +0900, Fujii Masao wrote:
On Thu, Dec 4, 2008 at 6:29 PM, Simon Riggs [EMAIL PROTECTED] wrote:
The only sensible settings are
synchronous_commit = on, synchronous_replication = on
Greetings!
On Fri, Dec 5, 2008 at 6:59 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-12-05 at 16:00 +0900, Fujii Masao wrote:
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao [EMAIL PROTECTED] wrote:
I was expecting you to have walreceiver and startup share an end of WAL
address via
On Thursday 04 December 2008 15:09, Gregory Stark wrote:
tmp [EMAIL PROTECTED] writes:
Also, it is my impression that many people use LIMIT to minimize the
evaluation time of sub queries from which the outer query only needs a
small subset of the sub query output.
I've seen lots of
--- repost to hackers as suggested by RhodiumToad ---
hi,
i tried to test new visibility map feature.
to do so i:
1. fetched postgresql sources from cvs
2. compiled
3. turned autovacuum off
4. started pg
5. ran this queries:
- CREATE TABLE test_1 (i INT4);
- CREATE TABLE test_2 (i INT4);
-
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
[EMAIL PROTECTED] wrote:
First run - without visibility maps, timing of vacuums:
Time: 267844.822 ms
Time: 138854.592 ms
Time: 305467.950 ms
Time: 487133.179 ms
Second run - on head:
Time: 252218.609 ms
Time: 234388.763 ms
Time:
Guillaume Smet wrote:
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
[EMAIL PROTECTED] wrote:
First run - without visibility maps, timing of vacuums:
Time: 267844.822 ms
Time: 138854.592 ms
Time: 305467.950 ms
Time: 487133.179 ms
Second run - on head:
Time: 252218.609 ms
Time:
Pavan Deolasee wrote:
/*
* We don't need to lock the page, as we're only looking at a single
bit.
*/
result = (map[mapByte] (1 mapBit)) ? true : false;
Isn't this a dangerous assumption to make ? I am not so sure that even a bit
can be read atomically on all platforms.
Pavan Deolasee wrote:
ISTM that the PD_ALL_VISIBLE flag and the visibility map bit can be set at
the end of pruning operation if we know that there are only tuples visible
to all transactions left in the page.
Right.
The way pruning is done, I think it
would be straight forward to get this
On Sat, Dec 6, 2008 at 7:57 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Umm, what non-atomic state could the bit be in? Half-set, half-cleared? Or
do you think that if some other bit in proximity is changed, the other bit
would temporarily flip 0-1-0, or something like that? I don't
Pavan Deolasee wrote:
On Sat, Dec 6, 2008 at 7:57 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Umm, what non-atomic state could the bit be in? Half-set, half-cleared? Or
do you think that if some other bit in proximity is changed, the other bit
would temporarily flip 0-1-0, or something
Pavan Deolasee wrote:
/*
* Size of the bitmap on each visibility map page, in bytes. There's no
* extra headers, so the whole page minus except for the standard page
header
* is used for the bitmap.
*/
#define MAPSIZE (BLCKSZ - SizeOfPageHeaderData)
ISTM that we should MAXALIGN the
On 2008-12-06, at 11:29, David Lee Lambert wrote:
I use ORDER BY random() LIMIT :some_small_number frequently to get
a feel
for data. That always builds the unrandomized relation and then
sorts it. I
guess an alternate path for single-table queries would be to
randomly choose
a block
Sorry for top posting but we are getting a bit far afield from the
original topic. I followed up the tests I did last night:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00369.php
I benchmarked 100 iterations of EXPLAIN on the query Greg Stark put
together as a synthetic benchmark
Looking for a way to limited a user to a specific set of queries. I don't think
this can be done right now ... or can it? Has this feature request surfaced in
the past?
I currently need this as an extra security measure for a libpq client app (want
to block arbitrary queries from malicious
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security measure for a libpq
client
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries.
I don't think this can be done right now ... or can it? Has this
feature request surfaced in the
It's slow because there's no way around running through the entire
input. The optimization tmp is talking about wouldn't be relevant
becase there is an order by clause which was precisely why I I said it
was a fairly narrow use case. Most people who use limit want a
specific subset even if
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature
That might only be the case when the pg_statistic record is in shared
buffers.
Also I wonder if eqjoinsel and company might need to be made more
toast-aware by detoasring all the things it needs once rather than
every time it accesses them.
greg
On 6 Dec 2008, at 06:19 PM, Robert Haas
Greg Smith wrote:
On Fri, 5 Dec 2008, Robert Treat wrote:
Might I suggest you collect all of these various arguments (both for and
against) and patches into a wiki page on the developers wiki?
I'm getting the feeling this is going to take a while to sort out too.
Page with most of the
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new occurrences be introduced.
Is there anything in the source that
Andrew Chernow wrote:
I don't think view-based security solves my problem. I need to limit
a user to 20 fixed queries, for example. That means the user cannot
execute SELECT NOW() or SELECT 'hello world'. The user can only
execute a pre-defined list of queries.
Put your queries in
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of --disable-row-acl options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't remove features
Patch applied, thanks.
---
Robert Haas wrote:
I had a deeper look at this now. The patch looks clean and applies without
any problems, regression tests passes. However, ATRewriteTables() has a
problem when adding
Abhijit Menon-Sen wrote:
At 2008-09-22 12:54:34 -0500, [EMAIL PROTECTED] wrote:
can we tell there is consensus in create a new has_sequence_privilege()?
Abhijit will you make it? if not i can make a try...
Yes, I'll do it.
This hasn't been done so I added it to the TODO list.
--
FWIW,
I have experienced some oddities in performing SELECT statements after
restarting on an 8.2 system, whereby I occasionally would get a ton of
duplicate records when I would do a select statement (my assumption is that
they are deleted tuples being returned). If I executed the same select
Hi folks,
Was recently poked and reminded that this patch may be of interest to
the community. It was mostly done as an academic exercise, just to see
how it works, and so it has a rather hackish feel. The patch adds the
sequence owner, if available, to psql's \d sequence output, as
suggested
28 matches
Mail list logo
