KaiGai Kohei wrote:
We are going to need to come up with specific answers to these issues
soon.
The origion of issue is simple.
Whether we should support to activate (not only compile) two or more
security
mechanism in same time, or not.
In my opinion, it is not a frequent situation, and it
Hello
this patch carry support for named and mixed notation - more detailed
described at http://archive.adaic.com/standards/83rat/html/ratl-08-03.html.
This use ADA syntax - name = value, that is conntroversal and
problematic - so I expect change of syntax.
Regards
Pavel Stehule
***
Peter Eisentraut wrote:
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based
row
On Fri, 2008-12-12 at 02:23 +, Greg Stark wrote:
The existing sampling mechanism is tied to solid statistics. It
provides the correct sample size to get a consistent confidence range
for range queries. This is the same mathematics which governs election
polling and other surveys. The
On Thu, 2008-12-11 at 18:52 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2008-12-11 at 22:29 +, Gregory Stark wrote:
And I would like it even more if the sample size increased according
to table size, since that makes ndistinct values fairly random for
Here is an updated version of pg_stat_statements.
[Changes]
- A new GUC variable 'explain_analyze_format' is added.
- Statistics counters are converted into a variable 'BufferStats'.
Vladimir Sitnikov sitnikov.vladi...@gmail.com wrote:
Can I ask my question once again?
Why don't you want to
Hi,
On Fri, Dec 12, 2008 at 1:34 PM, Aidan Van Dyk ai...@highrise.ca wrote:
* Fujii Masao masao.fu...@gmail.com [081211 23:00]:
Hi,
Or, should I
create the feature for the user to confirm whether it's in synch rep via
SQL?
I
I attached patch which add capability to reserve space on page for future
upgrade. It is mandatory for future in-place upgrade implementation. This patch
contains basic infrastructure not preupgrade script itself. I'm going to send
WIP preupgrade script today in separate mail.
This patch
On Fri, Dec 12, 2008 at 4:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
The existing sampling mechanism is tied to solid statistics. It
provides the correct sample size to get a consistent confidence range
for range queries. This is the same mathematics which governs election
polling and
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Pavan Deolasee wrote:
I can do some if we don't have already.
Oh, yes please!
I did some tests today with pgbench on a decent SMP machine. The goal
was to see if multiple clients (20 in the test)
On Thu, Dec 11, 2008 at 10:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I had this idle thought too, but I didn't write it down because...
ought to be, but it seems like it ought to be possible to determine
that given a desired maximum error in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 déc. 08 à 12:58, Peter Eisentraut a écrit :
The current proposed patch allocates the following psql \d commands:
[...]
In an idle second I thought, how about F for foreign, but of
course \dF* is already used for full-text search. We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 déc. 08 à 13:11, Pavan Deolasee a écrit :
I did some tests today with pgbench on a decent SMP machine. The goal
was to see if multiple clients (20 in the test) tries to update tuples
in different data blocks, if the EX lock on the VM page
Dimitri Fontaine wrote:
Le 12 déc. 08 à 12:58, Peter Eisentraut a écrit :
In an idle second I thought, how about F for foreign, but of course
\dF* is already used for full-text search. We could overload the F,
but it might be weird.
Other ideas?
What about \dM prefix, M standing for
Zdenek Kotala wrote:
I attached patch which add capability to reserve space on page for
future upgrade. It is mandatory for future in-place upgrade
implementation. This patch contains basic infrastructure not preupgrade
script itself. I'm going to send WIP preupgrade script today in separate
On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote:
what do you thing about?
select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
example
select dosome(10,20,30, SET flaga = true, flagb = false)
I think AS read more naturally because you expect the parameter to
come
first, not the
Now I have a question about the FDW C interface. The way I understand
it, an SQL/MED-enabled server and a FDW each have a specific API by
which they communicate. Supposedly, each database vendor should be able
to ship a binary library for its FDW and each SQL/MED-enabled server
should be
The current proposed patch allocates the following psql \d commands:
\dw show foreign-data wrappers
\dr show foreign servers
\dm show user mappings
One might object that this allocates valuable letters for infrequently
used functionality.
In an idle second I thought, how about F
Kurt Harriman harri...@acm.org writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
This would build one file - main.c - as C++ (necessary
because
Alvaro Herrera wrote:
What about \dM prefix, M standing for MED? It seems free in my 8.3 psql
here.
So \dMf for foreign servers, \dMu for user mappings, etc? That seems good.
I find the mixed case commands somewhat inconvinient -- too easy to make
typing mistakes, also slow to enter. If
KaiGai Kohei wrote:
I would like to be able to assign SQL-level ACLs and SELinux labels to
the same row at the same time in the same build, and have the system
enforce both on top of each other.
In my opinion, it makes more pains (user-interface, performance, complexity
of implementation and
Bramandia Ramadhana braman...@gmail.com writes:
As per title, what is the lifetime of the virtual tuple TupleTableSlot*
returned by ExecProcNode?
Until you next call that same plan node.
regards, tom lane
--
Sent via pgsql-hackers mailing list
2008/12/12 David E. Wheeler da...@kineticode.com:
On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote:
what do you thing about?
select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
example
select dosome(10,20,30, SET flaga = true, flagb = false)
I think AS read more naturally
On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote:
Quite possibly a terminology problem.. I my case I said sync rep
meaning the mode such that the transaction doesn't commit successfully
for my PG client until the xlog record has been streamed to the
client... and I understand that
If we use some type of integer, I suggest using this structure for
pg_security:
CREATE TABLE pg_security(
relid oid,
secid int2,
secacl aclitem[],
secext TEXT
);
This allows the per-row value to be a simple int2.
Alvaro Herrera alvhe...@commandprompt.com writes:
Dimitri Fontaine wrote:
What about \dM prefix, M standing for MED? It seems free in my 8.3 psql
here.
So \dMf for foreign servers, \dMu for user mappings, etc? That seems good.
I'd suggest e for external. M for management is a pretty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 déc. 08 à 14:14, Ian Caulfield a écrit :
unpopular, and '=' et al conflict with operators, would verilog-style
syntax - eg function( .param(value) ) - be an idea?
Ok, time to revisit the classics then ;)
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I attached patch which add capability to reserve space on page for
future upgrade. It is mandatory for future in-place upgrade
implementation. This patch contains basic infrastructure not
preupgrade script itself. I'm going to send WIP
2008/12/12 Dimitri Fontaine dfonta...@hi-media.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 12 déc. 08 à 14:14, Ian Caulfield a écrit :
unpopular, and '=' et al conflict with operators, would verilog-style
syntax - eg function( .param(value) ) - be an idea?
Ok, time to
David E. Wheeler da...@kineticode.com writes:
As a Perl hacker, I'm strongly biased toward =, but I guess AS isn't
*too* bad. At least it's the same number of characters. Is - right out?
It's just as bad as = from the perspective of usurping a probable
user-defined operator name.
I think the
Tom Lane wrote:
1. Ensure that a snapshot is set before doing parse analysis of any
non-utility command. (We *must* not set a snap before LOCK or a
transaction control command, and it seems best to not do it for any
utility command.) One issue here is that this would change the behavior
On Dec 12, 2008, at 2:33 PM, Dimitri Fontaine wrote:
Ok, time to revisit the classics then ;)
http://www.gigamonkeys.com/book/functions.html#keyword-parameters
That would give us things like this:
SELECT foo(1, :name 'bar', :quantity 10);
As colon character does not appear in the list of
On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:
So I think that really this is never going to fly unless it uses a
keyword-looking reserved word. And we're not going to take some short
word that's not reserved now and suddenly make it so. So, despite
Pavel's objection that the AS syntax proposal
David E. Wheeler da...@kineticode.com writes:
I'm okay with AS if that's the way it has to be, but what about a
colon right at the end of the label?
Hmm ... a colon isn't considered to be an operator name, so this
wouldn't break any existing usage. I'm a little bit worried about
what we
2008/12/12 David E. Wheeler da...@kineticode.com:
On Dec 12, 2008, at 2:39 PM, Tom Lane wrote:
So I think that really this is never going to fly unless it uses a
keyword-looking reserved word. And we're not going to take some short
word that's not reserved now and suddenly make it so. So,
* Simon Riggs si...@2ndquadrant.com [081212 08:20]:
2. Commit will wait *until* full sync rep is available. So we don't
allow it until standby fails and also don't allow it if standby goes
down.
This provides Highest Transaction Durability, though is fairly
fragile. Other systems recommend
Peter Eisentraut wrote:
Now the way I read the FDWs you provide (default and pgsql), you are
creating your own API for initialization and options validation that is
not in the standard. That would appear to contradict the idea of a
standard interface. I understand that option validation is
How about IS or INTO?
param_name IS 3
param_name IS 'some string value'
3 INTO param_name
'some string value' INTO param_name
On Fri, Dec 12, 2008 at 8:47 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2008/12/12 David E. Wheeler da...@kineticode.com:
On Dec 12, 2008, at 2:39 PM, Tom
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
1. Ensure that a snapshot is set before doing parse analysis of any
non-utility command.
I think this is the easiest way out, and the most robust -- we won't be
bitten by some other operation that the parser may think of
Rod Taylor rod.tay...@gmail.com writes:
How about IS or INTO?
IS isn't a fully reserved word, and INTO seems pretty weird for this.
(IS is a type_func_name_keyword, so maybe we could make it work anyway,
but it sounds a bit fragile.)
regards, tom lane
--
Sent via
In my gripe/suggestion here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00642.php
I noted that it might be nice to handle check constraints over
composite types. It turns out that table check constraints are not
enforced during casts:
postgres=# create table foo(f1 int, f2 int,
On Dec 12, 2008, at 2:47 PM, Pavel Stehule wrote:
it's look well, but I still prefer some combination with =
name: = ''
name: = '''
:name = ''
$name = ..
$name = ..
Maybe I am too conservative
Given that the colon already indicates This label corresponds to that
value, the other operator
On Fri, Dec 12, 2008 at 09:00:52AM -0500, Rod Taylor wrote:
How about IS or INTO?
param_name IS 3
param_name IS 'some string value'
that wouldn't work with NULL would it? for example is:
a IS NULL
checking if identifier 'a' IS NULL, or if you're giving NULL to
parameter 'a'.
3 INTO
right at the end of the label? A cast is two colons, so no conflict there:
SELECT foo(1, name: 'bar', quantity: 10);
it's look well, but I still prefer some combination with =
name: = ''
name: = '''
:name = ''
$name = ..
$name = ..
hmm :( $name isn't possible
:name is in conflict with
I wrote:
Rod Taylor rod.tay...@gmail.com writes:
How about IS or INTO?
IS isn't a fully reserved word, and INTO seems pretty weird for this.
(IS is a type_func_name_keyword, so maybe we could make it work anyway,
but it sounds a bit fragile.)
Actually, there's an obvious counterexample for
David E. Wheeler wrote:
Coming to this a bit late, but it seems to me that, while it makes sense
to assign a label to a value using AS, it's kind of weird to use it to
assign a value to a label.
SELECT foo( bar = 'ick', baz = 'ack' );
SELECT foo( bar AS 'ick', baz AS 'ack' );
We could do it
I'm okay with AS if that's the way it has to be, but what about a colon
right at the end of the label? A cast is two colons, so no conflict there:
SELECT foo(1, name: 'bar', quantity: 10);
No doubt I'm missing something…
I'd just like to mention that there are two different cases to
2008/12/12 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
David E. Wheeler wrote:
Coming to this a bit late, but it seems to me that, while it makes sense
to assign a label to a value using AS, it's kind of weird to use it to
assign a value to a label.
SELECT foo( bar = 'ick', baz
On Fri, Dec 12, 2008 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
AFAICS, marginal enlargements in the sample size aren't going to help
much for ndistinct --- you really need to look at most or all of the
table to be guaranteed anything about that.
Well you only need to maintain a fixed
On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:
I discussed about this form with Tom.
I thing so following should be readable:
name: [ optional = ] value
SELECT foo( bar: 'ick', baz: 'ack' );
SELECT foo( bar: = 'ick', baz: = 'ack' );
or
SELECT foo( bar: = 'ick', baz: = 'ack' );
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 11, 2008 at 10:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe so. If we stick to the other design (end both lists at a preset
frequency threshold) then the math clearly goes through the same as
before, just with num_mcvs that are
Pavel Stehule pavel.steh...@gmail.com writes:
2008/12/12 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
We could do it the other way round:
SELECT foo( 'ick' AS bar, 'ack' AS baz);
I always assumed we were talking about it this way. Everywhere else in SQL AS
is followed by the
Peter Eisentraut wrote:
KaiGai Kohei wrote:
I would like to be able to assign SQL-level ACLs and SELinux labels
to the same row at the same time in the same build, and have the
system enforce both on top of each other.
In my opinion, it makes more pains (user-interface, performance,
2008/12/12 David E. Wheeler da...@kineticode.com:
On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote:
I discussed about this form with Tom.
I thing so following should be readable:
name: [ optional = ] value
SELECT foo( bar: 'ick', baz: 'ack' );
SELECT foo( bar: = 'ick', baz: = 'ack' );
On Fri, 2008-12-12 at 06:44 -0500, Robert Haas wrote:
On Fri, Dec 12, 2008 at 4:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
The existing sampling mechanism is tied to solid statistics. It
provides the correct sample size to get a consistent confidence range
for range queries. This is
On Dec 12, 2008, at 3:57 PM, Gregory Stark wrote:
In any case this is all weird. SQL isn't C and doesn't have random
bits of
punctuation involved in syntax. It uses whole words for just about
everything.
Anything you do using punctuation characters is going to look out of
place.
Well,
On Dec 12, 2008, at 3:56 PM, Pavel Stehule wrote:
Hrm. I can see that, I guess. In that case, though, I think I'd
prefer the
colon at the beginning of the parameter label:
SELECT foo( :bar = 'ick', :baz = 'ack' );
this syntax is used yet
David E. Wheeler da...@kineticode.com writes:
Hrm. I can see that, I guess. In that case, though, I think I'd prefer
the colon at the beginning of the parameter label:
SELECT foo( :bar = 'ick', :baz = 'ack' );
That's ugly, and incompatible with ecpg syntax, and what's the redeeming
value
On Fri, 2008-12-12 at 09:35 -0500, Tom Lane wrote:
AFAICS, marginal enlargements in the sample size aren't going to help
much for ndistinct --- you really need to look at most or all of the
table to be guaranteed anything about that.
But having said that, I have wondered whether we should
Greg Stark st...@enterprisedb.com writes:
On Fri, Dec 12, 2008 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that, I have wondered whether we should consider
allowing the sample to grow to fill maintenance_work_mem
Hm, so I wonder what this does to the time analyze takes. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 12 déc. 08 à 15:57, Gregory Stark a écrit :
These don't solve anything. There's nothing stopping you from
defining a unary
prefix operator = or =
That's why I'm preferring the common-lisp syntax of :param value, or
its variant param: value.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
We could do it the other way round:
SELECT foo( 'ick' AS bar, 'ack' AS baz);
Yeah, that's the direction I had always assumed that we would use,
if AS is the chosen syntax for this.
regards, tom lane
--
On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
That's why I'm preferring the common-lisp syntax of :param value, or its
variant param: value.
FWIW there is no such common-lisp syntax. Colon is just a regular
symbol character and :param is just a regular symbol
any news on that front ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2008-12-12 at 06:44 -0500, Robert Haas wrote:
It is a pretty well-known mathematical fact that for something like an
opinion poll your margin of error does not depend on the size of the
population but only on the size of your sample.
Yes, I
Gregory Stark st...@enterprisedb.com writes:
For that matter, if we do consider sampling 5% of the table we may as well
just go ahead and scan the whole table. It wouldn't take much longer and it
would actually produce good estimates.
Yeah. Anything over a small fraction of a percent is going
Nathan Boley npbo...@gmail.com wrote:
Can anyone suggest a good data set to test this sort of question on?
Where we have the biggest problem with bad estimates is on complex
searches involving many joins where the main criterion limiting the
result set is a name. The estimate based on the
On Fri, Dec 12, 2008 at 10:31 AM, Greg Stark st...@enterprisedb.com wrote:
On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
That's why I'm preferring the common-lisp syntax of :param value, or its
variant param: value.
FWIW there is no such common-lisp syntax.
On Dec 12, 2008, at 4:06 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Hrm. I can see that, I guess. In that case, though, I think I'd
prefer
the colon at the beginning of the parameter label:
SELECT foo( :bar = 'ick', :baz = 'ack' );
That's ugly, and incompatible
I tried to summarize the proposed options, as follows:
o : meritx : demeritX : unacceptable demerit
* 1 security system column, 1 security feature (DAC or MAC)
o It suitable for a single security system column implementation.
x If a user want to use both of DAC and MAC
Which raises the issue, if we could get better statistics by passing
the whole table, why not do that when VACUUM ANALYZE is run?
I think the reason is because the next autovacuum would undo it.
Perhaps a table-level option to scan the whole table instead of
estimating would be appropriate?
.
On Fri, 2008-12-12 at 16:10 +, Gregory Stark wrote:
Right, but increasing our sample size by a factor of 150 for a 100M
row table doesn't seem like a reasonable solution to one metric being
bogus.
For that matter, if we do consider sampling 5% of the table we may as
well just go ahead
On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
If you want ANALYZE to be cheap then you simply don't get to have
a trustworthy value of ndistinct.
Understood, but a cheap ANALYZE isn't always a higher priority than all
other considerations.
Solutions can also include
* allowing user to
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
Hmm ... actually, ecpg might be a problem here anyway. I know it has
special meaning for :name, but does it allow space between the colon
and the name? If it does then the colon syntax loses. If it doesn't
No. Here's the lexer rule:
Robert Haas robertmh...@gmail.com writes:
Obviously sandwhiching two values in one column is not going to work.
The only question here is whether it's important to simultaneously
support both DAC and MAC. As far as I can see, KaiGai is the only one
arguing that we don't need to do that
On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
Perhaps a better plan is to try to de-emphasize use of ndistinct,
though I concede I have no idea how to do that.
We don't actually care about the accuracy of the ndistinct much, just
the accuracy of our answer to the question given work_mem
Robert Haas escribió:
Which raises the issue, if we could get better statistics by passing
the whole table, why not do that when VACUUM ANALYZE is run?
I think the reason is because the next autovacuum would undo it.
Is there any way to merge the statistics? i.e. if a full table scan
is
Tom Lane escribió:
If you want ANALYZE to be cheap then you simply don't get to have a
trustworthy value of ndistinct.
But then, maybe it's not all that critical that ANALYZE is cheap. For
example, if we were to rework VACUUM ANALYZE so that on the same pass
that VACUUM cleans each heap page,
Simon Riggs si...@2ndquadrant.com writes:
The amount of I/O could stay the same, just sample all rows on block.
Lifting the sample size will help large tables. Will it be perfect? No.
But I'll take better over not working at all.
That will just raise the table size at which the problems
Robert Haas escribió:
Peter made an excellent point a few emails upthread: there seemed to
be consensus in the September CommitFest that we needed SQL-level
support for row and column level security before we talked about
implementing those features as part of SELinux. I don't see that
On Fri, 2008-12-12 at 16:10 +, Gregory Stark wrote:
Uhm, this is a survey of lots of different methods and does lots of
analysis.
I don't see any simple conclusions about stability. Perhaps I'm just
missing
it in the technical details. Could you point out exactly what part of
the
paper
Peter made an excellent point a few emails upthread: there seemed to
be consensus in the September CommitFest that we needed SQL-level
support for row and column level security before we talked about
implementing those features as part of SELinux. I don't see that
we're any closer to that
Robert Haas robertmh...@gmail.com wrote:
Which raises the issue, if we could get better statistics by
passing
the whole table, why not do that when VACUUM ANALYZE is run?
I think the reason is because the next autovacuum would undo it.
The table has 32.4 million rows.
On Fri, Dec 12, 2008 at 11:57 AM, Gregory Stark st...@enterprisedb.com wrote:
Obviously sandwhiching two values in one column is not going to work.
The only question here is whether it's important to simultaneously
support both DAC and MAC. As far as I can see, KaiGai is the only one
arguing
On Fri, 2008-12-12 at 17:05 +, Gregory Stark wrote:
Simon Riggs si...@2ndquadrant.com writes:
The amount of I/O could stay the same, just sample all rows on block.
Lifting the sample size will help large tables. Will it be perfect? No.
But I'll take better over not working at all.
Changes:
- added vacuum_delay_point() in gininsertcleanup
- add trigger to run vacuum by number of inserted tuples from
last vacuum. Number of inserted tuples represents number
of really inserted tuples in index and it is calculated as
tuples_inserted + tuples_updated -
Hi,
Alvaro Herrera wrote:
No, the signalling needed here is far simpler than Markus' IMessage
stuff.
Yup, see also Tom's comment [1].
For Postgres-R I'm currently multiplexing by embedding a message type in
the imessage data itself. So this part is certainly overlapping, yes.
Some of the
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 12, 2008 at 4:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
The existing sampling mechanism is tied to solid statistics.
Sounds great, but its not true. The sample size is not linked to data
volume, so how can it possibly give a
KaiGai Kohei wrote:
If we use some type of integer, I suggest using this structure for
pg_security:
CREATE TABLE pg_security(
relid oid,
secid int2,
secacl aclitem[],
secext TEXT
);
This allows the per-row value to
KaiGai Kohei wrote:
Also, having the per-row value always be present in the row and
controlled by the bitmask seems ideal; it avoids having to add a CREATE
TABLE option.
Sorry, I don't understand why it related to a CREATE TABLE option.
System columns are always allocated for any
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
If you want ANALYZE to be cheap then you simply don't get to have a
trustworthy value of ndistinct.
But then, maybe it's not all that critical that ANALYZE is cheap. For
example, if we were to rework VACUUM ANALYZE so that
On Fri, Dec 12, 2008 at 5:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
Incidentally we *do* do block sampling. We pick random blocks and then pick
random records within those blocks. This was new in, uh, 7.4? 8.0? Sometime
around then. It dramatically reduced the i/o requirements but there
Michael Meskes mes...@postgresql.org writes:
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
Hmm ... actually, ecpg might be a problem here anyway. I know it has
special meaning for :name, but does it allow space between the colon
and the name? If it does then the colon syntax
On Fri, 2008-12-12 at 14:03 -0300, Alvaro Herrera wrote:
Partial vacuum is a roadblock for this though :-(
Actually, perhaps its an enabler for looking at changed stats?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote:
Perhaps a better plan is to try to de-emphasize use of ndistinct,
though I concede I have no idea how to do that.
We don't actually care about the accuracy of the ndistinct much, just
the accuracy of
Alvaro Herrera alvhe...@commandprompt.com writes:
Is there any way to merge the statistics? i.e. if a full table scan
is done to compute precise statistics, and later a regular analyze scan
is done, then perhaps instead of clobbering the previous stats, you
merge them with the new ones, thus
Alvaro Herrera wrote:
Robert Haas escribi?:
Which raises the issue, if we could get better statistics by passing
the whole table, why not do that when VACUUM ANALYZE is run?
I think the reason is because the next autovacuum would undo it.
Is there any way to merge the statistics?
Alvaro Herrera wrote:
Tom Lane escribi?:
If you want ANALYZE to be cheap then you simply don't get to have a
trustworthy value of ndistinct.
But then, maybe it's not all that critical that ANALYZE is cheap. For
example, if we were to rework VACUUM ANALYZE so that on the same pass
that
On Fri, 2008-12-12 at 18:01 +, Greg Stark wrote:
I think you need to find two different formulas, one which represents
a clustered table and one which represents randomly distributed data.
Then you need a way to measure just how clustered the data is so you
know how much weight to give
Simon Riggs si...@2ndquadrant.com writes:
As I said, we would only increase sample for ndistinct, not for others.
How will you do that? Keep in mind that one of the things we have to do
to compute ndistinct is to sort the sample. ISTM that the majority of
the cost of a larger sample is going
1 - 100 of 135 matches
Mail list logo
