Luke,
> While I'm waiting to figure out how to get the size of the toast table, at
> least I can provide the speed of query with/without assumed compression on
> the 6K text columns.
Check out the table_size view in the newsysviews project. Andrew computed the
regular, toast, and index sizes as
While I'm waiting to figure out how to get the size of the toast table, at
least I can provide the speed of query with/without assumed compression on
the 6K text columns.
To insure that we're actually accessing the data in the rows, I do a regexp
query on the TOASTed rows:
mpptestdb=# select coun
Josh,
On 2/26/06 8:04 PM, "Josh Berkus" wrote:
> Check out SET STORAGE.
I just altered the MIVP data generator in Bizgres MPP to produce the usual
15 column table but with a 6K row size. You'd only expect a few tens of
bytes variance around the 6K, and the data is randomly chosen words from a
Luke,
> As Jim pointed out, we would need a real test to confirm the behavior,
> I'm not yet acquainted with the toast compression, so it's harder for me
> to compose a real test.
Check out SET STORAGE.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(e
Tom,
> No way. The entire point of information_schema is that it is standard;
> adding non-spec things to it renders it no better than direct access
> to the PG catalogs.
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the information_schema (like aggregates) because
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2006-02-10 at 11:58 -0500, Tom Lane wrote:
>> I suspect that the right thing is not to see this as a planner issue at
>> all, but to try to drive the choice off the context in which the plan
>> gets invoked. Possibly we could pass a "need random ac
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I guess I understand whay you are saying. However, I am not allowed to
> talk to you about it unless cores allow me. Probably we need some
> closed forum to discuss this kind of security issues.
Considering that you've already described the problem on pgs
Hannu,
On 2/26/06 12:19 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
>> On DBT-3 data, I've just run some tests meant to simulate the speed
>> differences of compression versus native I/O. My thought is that an
>> external use of gzip on a binary dump file should be close to the speed of
>> LZ
> On 2006-02-26, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >> > In further investigation, Akio Ishida found this kind of attack is
> >> > possible even with EUC_JP/UTF-8.
> >>
> >> How?
> >
> > The details have been sent to cores.
>
> I
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
> | > * Issue a warning when creating a constraint who's name is
> | > not unique within its (the constraint's) schema.
> |
> | I don't have a problem with it (once, I argued for fol
On Sun, Feb 26, 2006 at 07:36:01PM +0100, Michael Paesold wrote:
> SET check_function_bodies = off;
Hrm, thanks for pointing that out. However, this, thankfully, does not appear
to inhibit the validator at all. Rather, the PL's validator is left with the job
to respect it if need be:
jwp=# select
Clark C. Evans wrote:
| > * Issue a warning when creating a constraint who's name is
| > not unique within its (the constraint's) schema.
|
| I don't have a problem with it (once, I argued for following the spec
| constraint on this way back when), however I think this was proposed an
On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
| > * Forbidding the creation of a foreign key constraint where
| > the column list for the referenced table doesn't *exactly*
| > match a canidate key on that table.
|
| About the best we're likely to be able to do is change
Thomas Hallgren wrote:
Andrew Dunstan wrote:
Enumkit's makefile uses pgxs happily to make foo.so without the lib
prefix. The relevant portion reads like this:
MODULES = $(TYPENAME)
Yeah. But using MODULES your are assumed to have one object file per
module. I need to use MODULE_big.
Ühel kenal päeval, P, 2006-02-26 kell 09:31, kirjutas Luke Lonergan:
> Jim,
>
> On 2/26/06 8:00 AM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > Any idea on how decompression time compares to IO bandwidth? In other
> > words, how long does it take to decompress 1MB vs read that 1MB vs read
> >
James William Pye schrieb:
> On Sat, Feb 25, 2006 at 01:21:34PM -0700, I wrote:
>
>>From what I have seen of zope's restricted python, it does, or can, force its
>>restrictions by checking bytecode. I imagine a simple PL sitting on top of the
>>untrusted varient that merely implements a custom val
Luke Lonergan wrote:
> Jim,
>
> On 2/26/06 10:37 AM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > So the cutover point (on your system with very fast IO) is 4:1
> > compression (is that 20 or 25%?).
>
> Actually the size of the gzipp'ed binary file on disk was 65MB, compared to
> 177.5MB unco
Jim,
On 2/26/06 10:37 AM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> So the cutover point (on your system with very fast IO) is 4:1
> compression (is that 20 or 25%?).
Actually the size of the gzipp'ed binary file on disk was 65MB, compared to
177.5MB uncompressed, so the compression ratio is 3
On Sun, Feb 26, 2006 at 09:31:05AM -0800, Luke Lonergan wrote:
> Note that this filesystem can do about 400MB/s, and we routinely see scan
> rates of 300MB/s within PG, so the real comparision is:
>
> Direct seqscan at 300MB/s versus gunzip at 77.5MB/s
So the cutover point (on your system with ve
On 2006-02-26, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>> > In further investigation, Akio Ishida found this kind of attack is
>> > possible even with EUC_JP/UTF-8.
>>
>> How?
>
> The details have been sent to cores.
I wasn't asking out of
James William Pye wrote:
On Sun, Feb 26, 2006 at 01:08:52PM -0500, Tom Lane wrote:
That design is broken on its face, as the system does not guarantee to
call the validator.
Hrm. Other than language creations that do not specify a validator, at
what
times will Postgres not call the validato
On Sun, Feb 26, 2006 at 01:08:52PM -0500, Tom Lane wrote:
> That design is broken on its face, as the system does not guarantee to
> call the validator.
Hrm. Other than language creations that do not specify a validator, at what
times will Postgres not call the validator upon function creation?
--
James William Pye <[EMAIL PROTECTED]> writes:
> On Sat, Feb 25, 2006 at 06:36:19PM -0300, Alvaro Herrera wrote:
>> I'm not sure it's an issue now that we have pg_pltemplate, but in older
>> versions it's possible to create a language without setting a validator.
>> This would make the validator an
Josh Berkus writes:
> 2) Modify the newsysviews to be extensions of the information_schema views:
> e.g. information_schema.tables would have the SQL03 information, and
> information_schema.tables_pg would have pg-specific stuff like table
> size
> and last analyzed date.
No way.
Jim,
On 2/26/06 8:00 AM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> Any idea on how decompression time compares to IO bandwidth? In other
> words, how long does it take to decompress 1MB vs read that 1MB vs read
> whatever the uncompressed size is?
On DBT-3 data, I've just run some tests meant
Neil Conway <[EMAIL PROTECTED]> writes:
> toast_compress_datum() considers compression to be "successful" if the
> compressed version of the datum is smaller than the uncompressed
> version. I think this is overly generous: if compression reduces the
> size of the datum by, say, 0.01%, it is likely
On Sat, Feb 25, 2006 at 09:39:34PM -0500, Neil Conway wrote:
> It's true that LZ decompression is fast, so we should probably use the
> compressed version of the datum unless the reduction in size is very
> small. I'm not sure precisely what that threshold should be, however.
Any idea on how decom
> > > > > Sound good to pass PGconn to new-PQescapeString. Here is the
> > > > > proposed calling sequence for the new function:
> > > > >
> > > > > size_t PQescapeStringWithConn (const PGconn *conn, char
> > > *to, const
> > > > > char *from, size_t length)
> > > > >
> > > > > If this is ok, I
> > > > > But actually I'd argue that
> > > > > letting the client programmer supply the encoding is still a
> > > > > pretty dangerous practice. Your example demonstrates
> > that if the
> > > > > encoding PQescapeString is told is different from the
> > encoding the
> > > > > backend parser
> > > > But actually I'd argue that
> > > > letting the client programmer supply the encoding is still a
> > > > pretty dangerous practice. Your example demonstrates
> that if the
> > > > encoding PQescapeString is told is different from the
> encoding the
> > > > backend parser thinks is in
> > > But actually I'd argue that
> > > letting the client programmer supply the encoding is still a pretty
> > > dangerous practice. Your example demonstrates that if the encoding
> > > PQescapeString is told is different from the encoding the backend parser
> > > thinks is in use, problems resul
> On 2006-02-20, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > In further investigation, Akio Ishida found this kind of attack is
> > possible even with EUC_JP/UTF-8.
>
> How?
The details have been sent to cores.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)
Andrew Dunstan wrote:
Enumkit's makefile uses pgxs happily to make foo.so without the lib
prefix. The relevant portion reads like this:
MODULES = $(TYPENAME)
Yeah. But using MODULES your are assumed to have one object file per
module. I need to use MODULE_big.
Alvaro Herrera wrote:
You c
33 matches
Mail list logo
