On Sat, Oct 03, 2009 at 06:12:20PM -0500, Corey Tisdale wrote:
> We also weren't adding image data to blobs, we were bit mapping
> faceted data to blob and shifting to allow people to shop by artist or
> color or subject matter across millions of posters. Normalized tables
> just weren't cutt
On Sat, Oct 03, 2009 at 04:14:21PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > the decision to officially bless some code as being a cast
> > rather than "just" a function seems very arbitrary
>
> It's useful when the conversion semantics are sufficiently natural that
> you want the conversion
You may have nailed it. Everythig would have been indexed I. The order
it was grouped by, so perhaps the order in which things are indexed
and accesse is the kicker, or perhaps we've been consistantly lucky.
We also weren't adding image data to blobs, we were bit mapping
faceted data to blo
Corey Tisdale writes:
> We're coming from mysql 4, and changing the sort order changes the
> values of all columns as you would expect, given that you would expect
> a sort statement to affect grouping. This certainly isn't the only
> time I've used this syntax. I've been mysql user for ten
Most Database Administrators dont allow jpg/png/gifs into BLOB columns simply
because its Run-length
encoding and MUCH easier to store the picture's link e.g.
http://www.mywebsite.com/PictureOfFido.jpg
Oracle on the other hand can store multi-gb images into blobs then again you're
paying for t
We're coming from mysql 4, and changing the sort order changes the
values of all columns as you would expect, given that you would expect
a sort statement to affect grouping. This certainly isn't the only
time I've used this syntax. I've been mysql user for ten years, and
the outcome has b
Sam Mason writes:
> On Sat, Oct 03, 2009 at 01:05:49PM -0400, Tom Lane wrote:
>> but looking at this example, and presuming that you find that
>> it actually does something useful, I wonder whether they interpret
>> the combination of GROUP BY and ambiguous-per-spec ORDER BY
>> in some fashion sim
Sam Mason writes:
> On Sat, Oct 03, 2009 at 12:48:57PM -0400, Tom Lane wrote:
>> I think the reason CREATE CAST exists is exactly that the cast mechanism
>> *isn't* intended to provide conversions between any arbitrary pair of
>> datatypes. It's only intended to provide conversions in those cases
On Sat, Oct 03, 2009 at 01:05:49PM -0400, Tom Lane wrote:
> What you might be after is something like Postgres' DISTINCT ON
> feature
Yup, looks that way to me as well.
> I have never really played around with this aspect of MySQL ...
Me neither.
> but looking at this example, and presuming tha
On Sat, Oct 03, 2009 at 12:48:57PM -0400, Tom Lane wrote:
> I think the reason CREATE CAST exists is exactly that the cast mechanism
> *isn't* intended to provide conversions between any arbitrary pair of
> datatypes. It's only intended to provide conversions in those cases
> where the conversion
Corey Tisdale writes:
> SELECT
> meaningful_data,
> event_type,
> event_date
> FROM
> event_log
> GROUP BY
> event_type
> ORDER BY
> event_date DESC
Is event_type a primary key, or at least a candidate key, for this
table? (I would guess not based on the name.
Sam Mason writes:
> I have a large problem understanding the real purpose casts so maybe I'm
> missing something. My problem is that I don't understand the purpose
> of trying to provide a "standard" way of converting between arbitrary
> datatypes,
I think the reason CREATE CAST exists is exactl
Hi all,
I'm a recent MySQL convert, and I am having some difficulty with
syntax on grouping a table by a foreign key and returning only the
newest entry that matches. In MySQL, you can do something like
event_log
id
event_type
event_date
meaningful_data
SELECT
meaning
[ please don't top-post it's difficult to follow for those not directly
involved in the discussion ]
On Sat, Oct 03, 2009 at 12:14:19PM -0400, Martin Gainty wrote:
> is there a way to create a cast with assignment e.g.?
Hum, I'm unsure how this would help. Maybe more explanation would help?
On Sat, Oct 03, 2009 at 11:49:50AM -0400, Merlin Moncure wrote:
> On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason wrote:
> > it's still a computer and thus can't represent anything
> > with infinite precision (just numeric fractions in PG's case, let alone
> > irrational numbers).
>
> I don't quite ag
On Sun, Sep 27, 2009 at 11:18 AM, Sam Mason wrote:
> On Sun, Sep 27, 2009 at 06:05:51PM +0200, Gerhard Wiesinger wrote:
>> A google research has shown that Gregory Stark already worked on that issue
>> (see references below) but as far as I saw only on bitmap heap scans.
>
> Greg Stark's patches a
is there a way to create a cast with assignment e.g.?
CREATE CAST ((date,date) AS int4) WITH FUNCTION generate_series(date,date) AS
ASSIGNMENT;http://www.postgresql.org/docs/8.4/static/sql-createcast.html
?
Martin Gainty
__
Verzicht und Vertraulichkei
2009/10/3 Grzegorz Jaśkiewicz :
> depending on the countries, etc - keep currencies in 10.4 , or you can
> compromise to 10.3 , otherwise you might run into problems with rounding,
> etc.
Keeping more digits of precision than the application actually can use
is more likely to *cause* problems with
On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason wrote:
> On Sat, Oct 03, 2009 at 12:20:57PM +0100, Raymond O'Donnell wrote:
>> I thought the idea of NUMERIC was that the value was exact, avoiding
>> rounding problems that you might get with other floating-point types?
>
> Nope, sorry it's still a compu
On Sat, Oct 03, 2009 at 12:20:57PM +0100, Raymond O'Donnell wrote:
> I thought the idea of NUMERIC was that the value was exact, avoiding
> rounding problems that you might get with other floating-point types?
Nope, sorry it's still a computer and thus can't represent anything
with infinite precis
On Fri, Oct 02, 2009 at 09:48:14PM +, Tim Landscheidt wrote:
> Sam Mason wrote:
> > 8.4 has a generate_series(timestamp,timestamp,interval) which would seem
> > to be a bit more flexible than you want.
>
> Yes, I know :-). But as "generate_series(A, B, C)" can also
> be written as "A + genera
2009/10/3 Grzegorz Jaśkiewicz :
> depending on the countries, etc - keep currencies in 10.4 , or you can
> compromise to 10.3 , otherwise you might run into problems with rounding,
> etc.
I myself don't find it useful to store currency values that include
fractions of a cent. I'm sure that there a
I understand it's kind of a survey, so to answer the question from my point
of view:
The "money" data type is not useful at all.
--
Filip Rembiałkowski
JID,mailto:filip.rembialkow...@gmail.com
http://filip.rembialkowski.net/
2009/10/3 Raymond O'Donnell
>
> You specify the locale at the initdb stage, not when compiling.
>
> Ray.
>
>
>
Yes, you're right. Got my wires crossed there. However, it still means
locale-per-cluster which is disappointing. Ideally we'd have collation and
locale per table or even per column.
On 03/10/2009 11:33, Thom Brown wrote:
> I've found that I unwittingly compiled PostgreSQL on my web server
> without specifying locale, and now the money type is represented in
You specify the locale at the initdb stage, not when compiling.
Ray.
On Sat, 2009-10-03 at 11:33 +0100, Thom Brown wrote:
> I've found that I unwittingly compiled PostgreSQL on my web server
> without specifying locale,
PostgreSQL isn't "compiled" with a locale or without one.
> and now the money type is represented in dollars. In order to change
> that, it woul
On 03/10/2009 11:53, Grzegorz Jaśkiewicz wrote:
> depending on the countries, etc - keep currencies in 10.4 , or you can
> compromise to 10.3 , otherwise you might run into problems with
> rounding, etc.
I thought the idea of NUMERIC was that the value was exact, avoiding
rounding problems that yo
2009/10/3 Peter Geoghegan
>
> Here's how I represent currency values:
>
> CREATE DOMAIN currency
> AS numeric(10,2);
>
>
>
See, I can understand why someone might take the extra step to create a
domain for storing monetary units. The fact that money is in the
documentation, but contains no note
depending on the countries, etc - keep currencies in 10.4 , or you can
compromise to 10.3 , otherwise you might run into problems with rounding,
etc.
Hi Thom,
Here's how I represent currency values:
CREATE DOMAIN currency
AS numeric(10,2);
I understand money has been deprecated. It has one obvious flaw that I
can think of: It cannot represent different currencies in different
tuples, with a currency_id field.
Regards,
Peter Geoghegan
--
I've noticed that while you can perform various calculations on a column of
type money, you can't use it or cast it as any other numeric type directly.
Furthermore, it appears that since the locale being applied to the type is
cluster-wide, you would need an entirely different cluster if say you h
On Fri, 2 Oct 2009, Simon Riggs wrote:
On Sun, 2009-09-27 at 18:05 +0200, Gerhard Wiesinger wrote:
So I saw, that even on sequential reads (and also on bitmap heap scan acces)
PostgreSQL uses only 8k blocks. I think that's a major I/O bottleneck.
A commercial software database vendor solved
On Fri, 2 Oct 2009, Greg Smith wrote:
On Fri, 2 Oct 2009, Gerhard Wiesinger wrote:
Larger blocksizes also reduce IOPS (I/Os per second) which might be a
critial threshold on storage systems (e.g. Fibre Channel systems).
True to some extent, but don't forget that IOPS is always relative to a
33 matches
Mail list logo
